Consider using the system SSL library, i.e., OpenSSL instead of `rusttls` / `ring`

[marco-cloudflare]

Summary

I thought that the native-tls flag would enable the native-ssl client but after close inspection, which is openssl in Linux, but, counter-intuitively, it actually just enables loading native certs using rustls and by extension ring, which has limitations e.g.: briansmith/ring#1631

See https://github.com/astral-sh/uv/blob/929e7c3ad96ff6b14aeb60527e6a4526ed24ec43/crates/uv-client/src/base_client.rs#L286C13-L286C59

This might the reason for problems like #9243

It seems that the reasoning behind this is for musl static compilation: #234 so I imagine that dynamic linking openssl is out of question. Another option could be enabling native-tls-vendored from reqwest which will static link openssl (it could be enabled only on musl builds, for others use native-tls) and have the uv's native-tls flag switch between reqwest use_rustls_tls() and use_native_tls()

Platform

Linux, but should affect any

Version

master branch

Python version

No response

[zanieb]

I'm a little hesitant to call this a bug. It looks like more of a request to dynamically link OpenSSL to work around unimplemented features in Ring?

[marco-cloudflare]

I'm a little hesitant to call this a bug. It looks like more of a request to dynamically link OpenSSL to work around unimplemented features in Ring?

I guess you're right, the category and title could be better. Now looking at the documentation, it does say that "Whether to load TLS certificates from the platform's native certificate store" with no mention that it's/it's not the system's native ssl lib.