Files
Zanie Blue b6854d77bf Upgrade reqwest to 0.13 (#18550)
The following user-facing changes are included here:

- `aws-lc` is used instead of `ring` for a cryptography backend
- Expands our certificate signature algorithm support to include
ECDSA_P256_SHA512, ECDSA_P384_SHA512, ECDSA_P521_SHA256,
ECDSA_P521_SHA384, and ECDSA_P521_SHA512
- `--native-tls` is deprecated in favor of a new `--system-certs` flag,
avoiding confusion with the TLS implementation used (we use `rustls` not
`native-tls`, see prior confusion at
https://github.com/astral-sh/uv/issues/11595)
- NASM is a new build requirement on Windows, it is required by `aws-lc`
on x86-64 and i386
- `rustls-platform-verifier` is used instead of `rustls-native-certs`
for system certificate verification
- On macOS, certificate validation is now delegated to
`Security.framework` (`SecTrust`). Performance when using
`--system-certs` is improved by avoiding exporting and parsing all the
certificates from the keychain at startup.
- On Windows, certificate validation is now delegated to
`CertGetCertificateChain` and `CertVerifyCertificateChainPolicy`
    - On Linux, certificate validation should be approximately unchanged
- Some previously failing chains may succeed, and some previously
accepted chains may fail; generally, this should result in behavior
closer matching browsers and other native applications
- macOS and Windows may now perform live OCSP fetches for early
revocation, which could add latency to some requests
- Empty `SSL_CERT_FILE` values are ignored (for consistency with
`SSL_CERT_DIR`)

The following internal changes are included here:

- Certificate loading has been refactored to use a newtype with helper
methods
- The certificate tests have been rewritten
- We use `webpki-root-certs` instead of `webpki-roots`, see
https://github.com/astral-sh/uv/pull/17543#discussion_r2820187691
- We request `identity` encoding for range requests, see
https://github.com/astral-sh/async_http_range_reader/pull/3#discussion_r2700194798
- Various dependencies (including forks) updates to versions which use
reqwest 0.13+

This is a replacement of #17543 with an updated description. See that
pull request for prior discussion. I've made the following changes from
the initial approach there:

- Previously, the `native-tls` TLS implementation was added which
included an OpenSSL build. We don't currently use the `native-tls`
implementation, but the `--native-tls` flag there was erroneously
updated to enable it.
- Previously, there was a `--tls-backend` flag to toggle between
`native-tls` and `rustls`. Since we currently always use `rustls`, this
is deferred to future work (if we need it at all).
- Previously, there were unintentional breaking changes to
`SSL_CERT_FILE` and `SSL_CERT_DIR` handling, including merging with the
base certificates instead of replacing them, dropping support for
OpenSSL hash-named certificate files, skipping deduplication of
certificates. Here, we retain use of `rustls-native-certs` for loading
certificates from the system as it handles these edge cases.


Closes https://github.com/astral-sh/uv/issues/17427

---------

Co-authored-by: salmonsd <22984014+salmonsd@users.noreply.github.com>
2026-03-23 13:22:19 -05:00

93 lines
2.1 KiB
TOML

doc-valid-idents = [
"PyPI",
"PubGrub",
"PyPy",
"CPython",
"GraalPy",
"ReFS",
"PyTorch",
"ROCm",
"XPU",
"PowerShell",
"CycloneDX",
"SemVer",
"AArch64",
"UV_DEV",
"UV_FROZEN",
"UV_ISOLATED",
"UV_LOCKED",
"UV_MANAGED_PYTHON",
"UV_NATIVE_TLS",
"UV_SYSTEM_CERTS",
"UV_NO_DEV",
"UV_NO_EDITABLE",
"UV_NO_ENV_FILE",
"UV_NO_INSTALLER_METADATA",
"UV_NO_MANAGED_PYTHON",
"UV_NO_PROGRESS",
"UV_NO_SYNC",
"UV_OFFLINE",
"UV_PREVIEW",
"UV_SHOW_RESOLUTION",
"UV_VENV_CLEAR",
"UV_VENV_SEED",
"..", # Include the defaults
]
disallowed-types = [
"std::fs::DirEntry",
"std::fs::File",
"std::fs::OpenOptions",
"std::fs::ReadDir",
"tokio::fs::DirBuilder",
"tokio::fs::DirEntry",
"tokio::fs::File",
"tokio::fs::OpenOptions",
"tokio::fs::ReadDir",
]
disallowed-methods = [
"std::fs::canonicalize",
"std::fs::copy",
"std::fs::create_dir",
"std::fs::create_dir_all",
"std::fs::hard_link",
"std::fs::metadata",
"std::fs::read",
"std::fs::read_dir",
"std::fs::read_link",
"std::fs::read_to_string",
"std::fs::remove_dir",
"std::fs::remove_dir_all",
"std::fs::remove_file",
"std::fs::rename",
"std::fs::set_permissions",
"std::fs::soft_link",
"std::fs::symlink_metadata",
"std::fs::write",
"tokio::fs::canonicalize",
"tokio::fs::copy",
"tokio::fs::create_dir",
"tokio::fs::create_dir_all",
"tokio::fs::hard_link",
"tokio::fs::metadata",
"tokio::fs::read",
"tokio::fs::read_dir",
"tokio::fs::read_link",
"tokio::fs::read_to_string",
"tokio::fs::remove_dir",
"tokio::fs::remove_dir_all",
"tokio::fs::remove_file",
"tokio::fs::rename",
"tokio::fs::set_permissions",
"tokio::fs::symlink_metadata",
"tokio::fs::try_exists",
"tokio::fs::write",
{ path = "std::os::unix::fs::symlink", allow-invalid = true },
{ path = "std::os::windows::fs::symlink_dir", allow-invalid = true },
{ path = "std::os::windows::fs::symlink_file", allow-invalid = true },
{ path = "tokio::fs::symlink", allow-invalid = true },
{ path = "tokio::fs::symlink_dir", allow-invalid = true },
{ path = "tokio::fs::symlink_file", allow-invalid = true },
]