feat: keep backwards compatibility with SSL_CERT_FILE without requiring --native-tls

[samypr100]

Summary

Small follow up to #2362 to check if SSL_CERT_FILE is set to enable --native-tls functionality. This maintains backwards compatibility with 0.1.17 and below users leveraging only SSL_CERT_FILE.

Closes #2400

Test Plan

Assuming SSL_CERT_FILE is already working via --native-tls, this is simply a shortcut to enable --native-tls functionality implicitly while still being able to let rustls-native-certs handle the loading of SSL_CERT_FILE instead of ourselves.

Edit: Manually tested by setting up own self-signed CA certificate bundle and set SSL_CERT_FILE to this and confirmed the loading happens without having to specify --native-tls.

[charliermarsh]

Should we instead change tls::load to add a certificate based on SSL_CERT_FILE? I think we would just call root_cert_store.add with the result of this: https://github.com/astral-sh/uv/pull/2351/files#diff-dcc1f69d132524500a0dcf217aa6db521517536daaf9364f3085961626fe722cR120

[samypr100]

I was thinking more towards delegating the parsing of SSL_CERT_FILE to rustls-native-certs as we already do when we combine (--native-tls with SSL_CERT_FILE).

The SSL_CERT_FILE is actually a CA bundle, meaning it can contain more than one cert. I believe we'd have to load each entry, get a vector of Certificates, and them add them to the builder one by one and handle potential incompatible cert errors along the way (we get this for free with rustls-native-certs).
I did see an API reqwest to load a pem bundle, but didn't see one to add them all at once, so we'd need to call add_root_certificate for each one in a loop as we build client.

Sidenote, I've just tested this current PR with creating my own self-signed CA's and set SSL_CERT_FILE to this and can confirm this solution would effectively delegate the parsing of SSL_CERT_FILE to rustls-native-certs properly (as we already do with the combination of --native-tls with SSL_CERT_FILE)

[samypr100]

If we're concerned with a user providing an invalid SSL_CERT_FILE path, how about a nice warning?

            let ssl_cert_file_exists = env::var_os("SSL_CERT_FILE")
                .map_or(false, |path| {
                    let path_exists = Path::new(&path).exists();
                    if !path_exists {
                        warn_user_once!("Ignoring invalid value from environment for SSL_CERT_FILE. File path {} does not exists.", path.to_string_lossy());
                    }
                    path_exists
                });

            let tls = tls::load(if self.native_tls || ssl_cert_file_exists {
                Roots::Native
            } else {
                Roots::Webpki
            })

[zanieb]

I think that seems reasonable.

[samypr100]

Added in 85d92e8

[zanieb]

Thanks! I was going to flag this too when looking at the changelog — I think this is a very reasonable behavior.

[charliermarsh]

Thanks!