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>
Pulled out of https://github.com/astral-sh/uv/pull/18517
I don't have aarch64 hardware available locally, but Claude posited:
> When an armv7 binary runs on an aarch64 kernel (e.g., armv7l
containers on aarch64 hosts, or 32-bit Raspberry Pi OS on 64-bit
hardware), /proc/cpuinfo reports aarch64-style feature flags instead of
armv7 flags. The existing check for "vfp" fails because aarch64 uses
"fp" instead.
>
> Add detection of the aarch64 "fp" feature flag (mandatory on all
aarch64 CPUs) as a discrete token, indicating hardware floating-point
support. This ensures uv selects the gnueabihf (hard-float) Python
variant instead of the gnueabi (soft-float) variant.
I reproduced this in https://github.com/astral-sh/uv/pull/18532
Under QEMU on aarch64 macOS, both the `vfp` and `fp` feature flags are
set.
Closes#18509
## Summary
This provides the scaffolding (CLI and initial `uv-audit` crate) for a
`uv audit` subcommand.
Closes#9189.
Tracking:
- [x] Core CLI scaffolding (this PR)
- [x] #18185
- [x] Audit core (probably a new `uv-audit` crate): #18124
- [ ] Bulk dependency audits with OSV
- [ ] Result presentation
- [ ] #18193
Things that also need to be done with the MVP:
- [ ] We should not audit workspace members by default (by definition,
they don't exist on indices and therefore don't have meaningful results
from vulnerability services).
- [ ] I need to ensure groups/etc. are being filtered by correctly,
right now we audit every single package in the lockfile unconditionally.
## Test Plan
Unit and integration tests commensurate with the new functionality.
---------
Signed-off-by: William Woodruff <william@astral.sh>
## Summary
This corrects a comment in the documentation to match the work done in
#16523, and to match the documentation for `--format`, which states:
```
/// Supports `requirements.txt`, `pylock.toml` (PEP 751) and CycloneDX v1.5 JSON output formats.
```
## Test Plan
N/A
---------
Co-authored-by: konstin <konstin@mailbox.org>
In #13302, there was an IO error without context. This error seems to be
caused by a symlink error. Switching as symlinking to `fs_err` ensures
these errors will carry context in the future.
## Summary
This is a prototype that I'm considering shipping under `--preview`,
based on [`light-the-torch`](https://github.com/pmeier/light-the-torch).
`light-the-torch` patches pip to pull PyTorch packages from the PyTorch
indexes automatically. And, in particular, `light-the-torch` will query
the installed CUDA drivers to determine which indexes are compatible
with your system.
This PR implements equivalent behavior under `--torch-backend auto`,
though you can also set `--torch-backend cpu`, etc. for convenience.
When enabled, the registry client will fetch from the appropriate
PyTorch index when it sees a package from the PyTorch ecosystem (and
ignore any other configured indexes, _unless_ the package is explicitly
pinned to a different index).
Right now, this is only implemented in the `uv pip` CLI, since it
doesn't quite fit into the lockfile APIs given that it relies on feature
detection on the currently-running machine.
## Test Plan
On macOS, you can test this with (e.g.):
```shell
UV_TORCH_BACKEND=auto UV_CUDA_DRIVER_VERSION=450.80.2 cargo run \
pip install torch --python-platform linux --python-version 3.12
```
On a GPU-enabled EC2 machine:
```shell
ubuntu@ip-172-31-47-149:~/uv$ UV_TORCH_BACKEND=auto cargo run pip install torch -v
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.31s
Running `target/debug/uv pip install torch -v`
DEBUG uv 0.6.6 (e95ca063b 2025-03-14)
DEBUG Searching for default Python interpreter in virtual environments
DEBUG Found `cpython-3.13.0-linux-x86_64-gnu` at `/home/ubuntu/uv/.venv/bin/python3` (virtual environment)
DEBUG Using Python 3.13.0 environment at: .venv
DEBUG Acquired lock for `.venv`
DEBUG At least one requirement is not satisfied: torch
warning: The `--torch-backend` setting is experimental and may change without warning. Pass `--preview` to disable this warning.
DEBUG Detected CUDA driver version from `/sys/module/nvidia/version`: 550.144.3
...
```
Zanie Blue