Repository navigation
Consider using the system SSL library, i.e., OpenSSL instead of rusttls / ring #11595
Description
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
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
Activity
zanieb commentedon Feb 18, 2025
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 commentedon Feb 18, 2025
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.
[-]Native-tls support is limited[/-][+]Consider using the system SSL library, i.e., OpenSSL instead of `rusttls` / `ring`[/+]Upgrade reqwest to 0.13 (#18550)
zanieb commentedon Mar 24, 2026
In #18550 we've renamed the
native-tlsflag tosystem-certsfor clarity, at least.tiran commentedon Jul 27, 2026
I found this ticket today when I was looking into PQC and crypto policy support for
uvtoday.I ran an experiment to see what it would take to support OpenSSL via reqwest native-tls as an optional compile-time feature. It does not look that complicated, but it would come with a maintenance overhead. Disclaimer: my experiment https://github.com/tiran/uv/pull/new/native-tls-support is mostly AI generated. I spent a couple of extra rounds to make the code more appealing and included a plan document.
zanieb commentedon Jul 27, 2026
Thanks for exploring it! Yeah I think it'd be fairly easy to implement but I worry about the maintenance / support burden. I'm not sure we're seeing enough demand for it.
What's your use-case?
tiran commentedon Jul 27, 2026
Compliance and standardization :)
Background: I'm part of a team at Red Hat that rebuilds Python wheels from sources for internal and external customers. We do this for multiple reasons, e.g. we want to have the sources for everything we deliver. Our wheels aren't manylinux wheels, too. Instead they are tight to system libraries and pre-installed RPMs -- like our system OpenSSL. We are providing container images for AI accelerator stacks like CUDA, ROCm, but also CPU. The images come with pre-configured
pipanduvthat install from our index instead of PyPI.I'm interested in a downstream rebuild of
uvwith OpenSSL, because we like to standardize on a few approved crypto libraries. All crypto libraries are configured through a crypto policy system. The policy is configured on the host system and automatically forwarded to containers by Podman. Since our wheel use OpenSSL from the OS, we can configure and update OpenSSL easily. For example ourcryptographywheel is built withOPENSSL_NO_VENDORto force system OpenSSL instead of vendoredopenssl-src.insanitybit commentedon Aug 10, 2026
Indeed, we have compliance obligations and want to standardize our OpenSSL configurations. It's really important for us to be able to run specific commands to say "we support these ciphers, we reject these" in order to satisfy audit requirements (and for our own sanity!). This is actually a blocker for our use of
uv, even though we love it!tiran commentedon Aug 10, 2026
@insanitybit @zanieb I'm happy to turn my proof of concept into a proper PR. I'd need some assistance to figure out CI and Rust best practices, though. I'm a novice Rust developer.
Paging @musicinmybrain. Ben is the package maintainer of
uvfor Fedora and EPEL. He might be interested in anuvbuild with system OpenSSL and Fedora crypto policy, too.michael-o commentedon Aug 10, 2026
@yurivict This might be interesting for you as the downstream port maintainer in FreeBSD to avoid the pain in the ass I had with rustls/openssl-probe#43
musicinmybrain commentedon Aug 24, 2026
I would be quite interested in this.
I’m not prepared to review nontrivial changes to the crypto support in
uv, so I would want to see any proposed patch robustly reviewed before considering a downstream patch. Even then, I would be concerned about long-term maintenance of any nontrivial downstream patch, especially considering the fast pace ofuvdevelopment and the consequences of making subtle errors in crypto code.I would much prefer to see support for using a system OpenSSL library merged and maintained in the official
uvrepository. At that point I would certainly start building Fedora’suvwith that option.konstin commentedon Aug 24, 2026
The main problem I expect are subtle behavior differences around custom cert support and error handling that would lead to setups passing with one uv distro and failing with another. Retry behavior with openssl would also be hard.
Add optional native-tls (OpenSSL) backend
Add optional native-tls (OpenSSL) backend
Add optional native-tls (OpenSSL) backend
Add optional native-tls (OpenSSL) backend