uv/docs/configuration/authentication.md
Charlie Marsh e61a221fef
Migrate from MdBook to MkDocs (#5062)
## Summary

We want to have consistency between the Ruff and uv documentation for
the upcoming release. We don't love the Ruff docs, but we'd rather have
consistency and then work towards improving them both, rather than have
two very-different documentation sites that both have weaknesses.

The setup here is simpler than in Ruff as: (1) we don't yet generate any
docs from Rust and (2) we don't try to reuse the README in the uv
documentation (which adds a lot of complexity in Ruff). So the change
here is mostly a 1-to-1 port to MkDocs.

## Test Plan

![Screenshot 2024-07-14 at 9 49
15 PM](https://github.com/user-attachments/assets/8bfb5b06-08ff-4329-b368-d9087b78996e)
2024-07-15 22:22:07 +00:00

3.3 KiB

Authentication

Git authentication

uv allows packages to be installed from Git and supports the following schemes for authenticating with private repositories.

Using SSH:

  • git+ssh://git@<hostname>/... (e.g. git+ssh://git@github.com/astral-sh/uv)
  • git+ssh://git@<host>/... (e.g. git+ssh://git@github.com-key-2/astral-sh/uv)

See the GitHub SSH documentation for more details on how to configure SSH.

Using a password or token:

  • git+https://<user>:<token>@<hostname>/... (e.g. git+https://git:github_pat_asdf@github.com/astral-sh/uv)
  • git+https://<token>@<hostname>/... (e.g. git+https://github_pat_asdf@github.com/astral-sh/uv)
  • git+https://<user>@<hostname>/... (e.g. git+https://git@github.com/astral-sh/uv)

When using a GitHub personal access token, the username is arbitrary. GitHub does not support logging in with password directly, although other hosts may. If a username is provided without credentials, you will be prompted to enter them.

If there are no credentials present in the URL and authentication is needed, the Git credential helper will be queried.

HTTP authentication

uv supports credentials over HTTP when querying package registries.

Authentication can come from the following sources, in order of precedence:

  • The URL, e.g., https://<user>:<password>@<hostname>/...
  • A netrc configuration file
  • A keyring provider (requires opt-in)

If authentication is found for a single net location (scheme, host, and port), it will be cached for the duration of the command and used for other queries to that net location. Authentication is not cached across invocations of uv.

Note --keyring-provider subprocess or UV_KEYRING_PROVIDER=subprocess must be provided to enable keyring-based authentication.

Authentication may be used for hosts specified in the following contexts:

  • index-url
  • extra-index-url
  • find-links
  • package @ https://...

See the pip compatibility guide for details on differences from pip.

Custom CA certificates

By default, uv loads certificates from the bundled webpki-roots crate. The webpki-roots are a reliable set of trust roots from Mozilla, and including them in uv improves portability and performance (especially on macOS, where reading the system trust store incurs a significant delay).

However, in some cases, you may want to use the platform's native certificate store, especially if you're relying on a corporate trust root (e.g., for a mandatory proxy) that's included in your system's certificate store. To instruct uv to use the system's trust store, run uv with the --native-tls command-line flag, or set the UV_NATIVE_TLS environment variable to true.

If a direct path to the certificate is required (e.g., in CI), set the SSL_CERT_FILE environment variable to the path of the certificate bundle, to instruct uv to use that file instead of the system's trust store.

If client certificate authentication (mTLS) is desired, set the SSL_CLIENT_CERT environment variable to the path of the PEM formatted file containing the certificate followed by the private key.