uv

uv copied to clipboard

Having set all the following environment variables, my expectation is that uv would behave the same way as pip when running uv pip install .

export UV_INDEX_URL="https://${NEXUS_USERNAME}:${NEXUS_PASSWORD}@${NEXUS_URL}:443/repository/pypi-proxy/simple"
export UV_EXTRA_INDEX_URL="https://${NEXUS_USERNAME}:${NEXUS_PASSWORD}@${NEXUS_URL}:443/repository/private-python-repo/simple"
export SSL_CERT_FILE=/path/to/trusted/certs/certs.crt
export SSL_CLIENT_CERT=/path/to/private/cert_then_key.pem

uv version is 0.2.17 and pip version is 24.1.1.

The private repo in question is an instance of Sonatype Nexus

Here is the pip.conf that is working using pip

[global]
index-url = {same as above UV_INDEX_URL}
extra-index-url = {{ same as above UV_EXTRA_INDEX_URL }}
client-cert = {{ same as above SSL_CERT_FILE }}
cert = {{ same as above SSL_CLIENT_CERT }}

Here is a full trace with private things redacted, but the TL;DR seems to be:

DEBUG Transient request failure for https://*****************/repository/private-python-repo/simple/xmlschema/, retrying: Request error: error sending request for url (https://*****************/repository/private-python-repo/simple/xmlschema/)
  Caused by: error sending request for url (https://*****************/repository/private-python-repo/simple/xmlschema/)
  Caused by: client error (Connect)
  Caused by: Connection reset by peer (os error 104)

Thank you!

Unfortunately I don't have any ideas here. cc @samypr100

Do you have server side logs for the failed connections?

hmm, hard to say. Connection reset by peer tells me that the handshake is failing for some unknown reason and like @zanieb mentioned its worth correlating with server logs to figure out exactly what the issue is. Alternatively, if there's other details you can share about the server's exact TLS configuration or how client certs are generated I can try to reproduce.

Normally you might see success in pip in situations like these if have something like trusted-host configured for pip anywhere on your system. Sidenote, the mTLS implementation uv is using is strict, not permissive but in such cases you'd likely get an error like invalid peer certificate.

It might be worth trying to debug using openssl s_client itself using -connect with -verify_return_error, maybe there is a hint somewhere there about the type of TLS error.

I'll give a shot at making a project that reproduces the error I'm seeing, but first I'll try and track down the server logs too see if there is anything obvious. Thank you for the help and suggestions @samypr100 / @zanieb 😄

Ok so this one was totally on me and possibly on pip being too permissive, and I could only see what was going wrong when getting into the logs for the Amazon ALB that was in front of nexus. What happened was that the load balancer had an incomplete certificate chain while the chain on the client side was complete. Some logging indicating this failure would be helpful but is out of scope for uv I think.

Thank you for the help!

Thank you for following up!