Closed mholt77 closed 7 months ago
Thanks for the report! I'm not sure what's going on here, it's all upstream of us now that we're using rustls-native-certs
.
Related:
No worries, will keep my eyes open for the --trusted-host
progress as may be able to trial it that way
If there's any way you can help us reproduce the issue or investigate with verbose logs e.g. RUST_LOG=trace uv pip install -v ...
that's the best bet to move this forward.
I have attached a snippet of the log below, it appears to be failing to connect here, it cycles through this several time before returning the error.
0.075847s 49ms TRACE hyper::client::pool checkout waiting for idle connection: ("https", packages.dns.ad.xyz.com)
0.075872s 49ms DEBUG reqwest::connect starting new connection: https://packages.dns.ad.xyz.com/
0.075890s 49ms TRACE hyper::client::connect::http Http::connect; scheme=Some("https"), host=Some("packages.dns.ad.xyz.com"), port=None
0.075921s DEBUG hyper::client::connect::dns resolving host="packages.dns.ad.xyz.com"
0.079257s 52ms DEBUG hyper::client::connect::http connecting to xxx
0.082095s 55ms DEBUG hyper::client::connect::http connected to xxx
0.082113s 55ms DEBUG rustls::client::hs No cached session for DnsName("packages.dns.ad.xyz.com")
0.082181s 55ms DEBUG rustls::client::hs Not resuming any session
0.082201s 55ms TRACE rustls::client::hs Sending ClientHello Message {
version: TLSv1_0,
payload: Handshake { .....
0.085173s 58ms TRACE rustls::client::hs We got ServerHello ServerHelloPayload {
legacy_version: TLSv1_2,
random: 02b36fd708ebb74373bc26e6f796bc289ce14b60d144bd486cc4bb4b8ac24329,
session_id: e96c4cbb3dfe7b1448d51201a3752a9c6f1ca048846ef276c297c2e014815b48,
cipher_suite: TLS13_AES_256_GCM_SHA384,
compression_method: Null,
extensions: [
SupportedVersions(
TLSv1_3,
),
KeyShare(
KeyShareEntry {
group: X25519,
payload: aca8a9529090f752aa450105beead313fc745d2f7cd121a52693d86d27d20b2c,
},
),
],
}
0.085207s 58ms DEBUG rustls::client::hs Using ciphersuite TLS13_AES_256_GCM_SHA384
0.085217s 58ms DEBUG rustls::client::tls13 Not resuming
0.085224s 58ms TRACE rustls::client::client_conn EarlyData rejected
0.085301s 58ms TRACE rustls::conn Dropping CCS
0.085312s 58ms DEBUG rustls::client::tls13 TLS1.3 encrypted extensions: [ServerNameAck, Protocols([ProtocolName(687474702f312e31)])]
0.085321s 58ms DEBUG rustls::client::hs ALPN protocol is Some(b"http/1.1")
0.085821s 59ms TRACE rustls::client::tls13 Server cert is [......
]
0.086041s 59ms TRACE hyper::client::pool checkout dropped for ("https", packages.dns.ad.xyz.com)
0.086059s 59ms WARN reqwest_retry::middleware Retry attempt #1. Sleeping 649.8106ms before the next attempt
....
2.626812s TRACE hyper::proto::h2::client client::dispatch::Sender dropped
2.626844s TRACE hyper::client::pool pool closed, canceling idle interval
h2::proto::connection::poll
2.626900s 0ms TRACE h2::proto::connection connection.state=Open
h2::codec::framed_write::FramedWrite::buffer frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2.626932s 0ms DEBUG h2::codec::framed_write send, frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2.626943s 0ms TRACE h2::frame::go_away encoding GO_AWAY; code=NO_ERROR
2.626951s 0ms TRACE h2::codec::framed_write encoded go_away, rem=17
2.626963s 0ms DEBUG h2::proto::connection Connection::poll; connection error, error=GoAway(b"", NO_ERROR, Library)
2.626972s 0ms TRACE h2::proto::connection -> already going away
2.626979s 0ms TRACE h2::proto::connection connection.state=Closing(NO_ERROR, Library)
2.626986s 0ms TRACE h2::proto::connection connection closing after flush
h2::codec::framed_write::FramedWrite::flush
2.627004s 0ms TRACE h2::codec::framed_write queued_data_frame=false
2.627041s 0ms TRACE h2::codec::framed_write flushing buffer
2.627053s 0ms DEBUG rustls::common_state Sending warning alert CloseNotify
2.627077s 0ms TRACE h2::proto::connection connection.state=Closed(NO_ERROR, Library)
2.627092s TRACE h2::proto::streams::streams Streams::recv_eof
h2::proto::streams::prioritize::clear_pending_capacity
Also to confirm that echo $SSL_CERT_FILE
returns /etc/ssl/certs/ca-certificates.crt
and echo $REQUESTS_CA_BUNDLE
returns /etc/ssl/certs/ca-certificates.crt
Resolved, appeared to be an issue with certificate mapping my end. Sorry!
Hey, I saw https://github.com/astral-sh/uv/issues/1474 should have resulted in uv being able to work via SSL_CERT_FILE, but when running.
I am still encountering
I have validated that my trust store and environment variables are correctly mapped, should the merge for 1474 not have fixed this?
Using uv has a lot of scope to speed up so many internal package deployments so would be very keen to get to test this further.
Thanks for all the great work so far on it!