Invalid peer certificate with --tls-no-verify

[zen-xu]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Issue description

I installed a pypi package published on nexus using the latest pixi on the company's intranet server, but encountered invalid peer certificate: UnknownIssuer

Expected behavior

--tls-no-verify should work

[zen-xu]

Additionally, version 0.28.2 does not have this issue.

It seems to be related to #1929

[baszalmstra]

That is strange! How did you install pixi?

[zen-xu]

download it from github

[zen-xu]

Or is it possible to provide an option for specifying a self-signed certificate?

[baszalmstra]

You should be able to add the certificate to your oses certificate store and it should be picked up.

Ill investigate the regression.

[zen-xu]

I have added the certificate to /etc/ssl/certs/, version 0.28.2 can recognize it well, but version 0.29.0 cannot.

[baszalmstra]

Ah this seems to be due to an update in uv: astral-sh/uv#6591 .

This is handled differently now between uv and pixi.. Looping in @tdejager . I think this kind of setup would also be much better for pixi but it would require a little refactoring. WDYT?

[baszalmstra]

@zen-xu As a workaround you could try setting the SSL_CERT_FILE and/or SSL_CLIENT_CERT environment variables as described here: https://docs.astral.sh/uv/configuration/authentication/#authentication-with-alternative-package-indexes

[tdejager]

@zen-xu As a workaround you could try setting the SSL_CERT_FILE and/or SSL_CLIENT_CERT environment variables as described here: https://docs.astral.sh/uv/configuration/authentication/#authentication-with-alternative-package-indexes

Are you sure that these are read from our library calls as well, some env variables uv reads from the command line modules only

[zen-xu]

This works

[benmoss]

Also running into the same thing, corporate MITM cert not getting respected by pixi when I use a pyproject file.

$ pixi init --pyproject
$ pixi add crane
  × default: error installing/updating PyPI dependencies
  ├─▶ Failed to prepare distributions
  ├─▶ Failed to fetch wheel: wow @ file:///private/tmp/wow
  ├─▶ Failed to install requirements from build-system.requires (resolve)
  ├─▶ No solution found when resolving: hatchling
  ├─▶ Request failed after 3 retries
  ├─▶ error sending request for url (https://pypi.org/simple/hatchling/)
  ├─▶ client error (Connect)
  ╰─▶ invalid peer certificate: UnknownIssuer

If I use a regular pixi.toml file this bug doesn't occur, so I agree it's due to uv changes rather than the switch to rustls-tls

[tdejager]

Yes, I need to map the trusted-hosts feature from uv to our codebase, just need to think of a good spot in the pixi.toml for it. I'll try to get to in next week.

[tdejager]

Also running into the same thing, corporate MITM cert not getting respected by pixi when I use a pyproject file.

$ pixi init --pyproject
$ pixi add crane
  × default: error installing/updating PyPI dependencies
  ├─▶ Failed to prepare distributions
  ├─▶ Failed to fetch wheel: wow @ file:///private/tmp/wow
  ├─▶ Failed to install requirements from build-system.requires (resolve)
  ├─▶ No solution found when resolving: hatchling
  ├─▶ Request failed after 3 retries
  ├─▶ error sending request for url (https://pypi.org/simple/hatchling/)
  ├─▶ client error (Connect)
  ╰─▶ invalid peer certificate: UnknownIssuer

If I use a regular pixi.toml file this bug doesn't occur, so I agree it's due to uv changes rather than the switch to rustls-tls

@benmoss in this case you get the MITM cert instead of the one from https://pypi.org right :)?