-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Use index URL instead of package URL for keyring credential lookups #12651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
In this version, when an index URL prefix is found, we will use that instead of the full package URL to look up credentials. This is probably the expected behavior, but is it possible some users now rely on the old behavior? If this is a concern, another option is to first check one and then the other, though keyring lookup can be slow. |
crates/uv-auth/src/middleware.rs
Outdated
@@ -477,13 +477,25 @@ impl AuthMiddleware { | |||
// URLs; instead, we fetch if there's a username or if the user has requested to | |||
// always authenticate. | |||
if let Some(username) = credentials.and_then(|credentials| credentials.username()) { | |||
debug!("Checking keyring for credentials for {username}@{url}"); | |||
keyring.fetch(url, Some(username)).await | |||
if let Some(index_url) = self.auth_indexes.auth_index_url_for(url) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's more that needs to change for the authentication middleware to become index-aware. We calculate the cache key above
// Fetches can be expensive, so we will only run them _once_ per realm and username combination
// All other requests for the same realm will wait until the first one completes
let key = (
Realm::from(url),
Username::from(
credentials
.map(|credentials| credentials.username().unwrap_or_default().to_string()),
),
);
but we should cache at the index level instead of the realm level.
It may be plausible to ship that separately? But it's part of the objective of #4583
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree this needs to be done. The main question is whether we still need to support realm-level caching for URLs not tied to an index. I think so, given that the BaseClient
can be used for multiple purposes. If not, this work would entail reworking our credential cache to operate at the index URL level instead of the realm level. If so, we'll need to support both.
I'm ok with adding that to the scope of this PR, but I also think this PR could be merged independently without causing surprising behavior (and would strictly be an improvement). My inclination is to merge separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main question is whether we still need to support realm-level caching for URLs not tied to an index. I think so, given that the BaseClient can be used for multiple purposes.
Yeah I think so too.
[...] I also think this PR could be merged independently without causing surprising behavior (and would strictly be an improvement). My inclination is to merge separately.
Works for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented this in #12717. We could either merge that into this PR if approved or merge it after this one.
Excited that you tackled this! |
I'd retitle to be more relevant to users (otherwise, I just have to do it on release) e.g.:
|
Some registries (like Azure Artifact) can require you to authenticate separately for every package URL if you do not authenticate for the /simple endpoint. These changes make the auth middleware aware of index URL endpoints and attempts to fetch keyring credentials for such an index URL when making a request to any URL it's a prefix of. Currently, if we find a prefix index URL we attempt to fetch keyring credentials for it. Otherwise we attempt to fetch for the full URL. Addresses part of #4056 Closes #4583
1d1fa4b
to
c015498
Compare
crates/uv/tests/it/pip_install.rs
Outdated
Keyring request for public@https://pypi-proxy.fly.dev/basic-auth | ||
Keyring request for [email protected] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I'm just missing this, but... is there a test case here where the keyring has credentials for the index level and we don't fallback to the realm request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly, is there a test case where the keyring has credentials for the full URL but not at the index or realm level?
(These would be achieved by tweaking EnvVars::KEYRING_TEST_CREDENTIALS, r#"{"pypi-proxy.fly.dev": {"other": "heron"}}"
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I'm just missing this, but... is there a test case here where the keyring has credentials for the index level and we don't fallback to the realm request?
That test is in the follow-on PR #12717 (which we can merge into this one).
Similarly, is there a test case where the keyring has credentials for the full URL but not at the index or realm level?
(These would be achieved by tweaking
EnvVars::KEYRING_TEST_CREDENTIALS, r#"{"pypi-proxy.fly.dev": {"other": "heron"}}"
)
I don't have this test, so I can add it.
…ndexes (#12717) The current uv behavior is to cache credentials either at the request URL or realm level. But in general, the expected behavior for indexes is to apply credentials at the index level (as implemented in #12651). This means that we also need to cache credentials at this level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Depends on #12651.
ae53704
to
0e59672
Compare
} | ||
|
||
#[test] | ||
fn add_full_url_in_keyring() -> Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zanieb Here is the full URL test. As discussed in another thread, we don't actually check the full URL in the keyring now for indexes, which is reflected here.
da2c4d8
to
b694b92
Compare
…ndexes (#12717) The current uv behavior is to cache credentials either at the request URL or realm level. But in general, the expected behavior for indexes is to apply credentials at the index level (as implemented in #12651). This means that we also need to cache credentials at this level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Depends on #12651.
b694b92
to
d7b6799
Compare
…ndexes (#12717) The current uv behavior is to cache credentials either at the request URL or realm level. But in general, the expected behavior for indexes is to apply credentials at the index level (as implemented in #12651). This means that we also need to cache credentials at this level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Depends on #12651.
Is this waiting on anything? |
No it’s ready |
I think it needs to be based on release/070 instead? |
Yeah I can do that this weekend |
…ndexes (#12717) The current uv behavior is to cache credentials either at the request URL or realm level. But in general, the expected behavior for indexes is to apply credentials at the index level (as implemented in #12651). This means that we also need to cache credentials at this level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Depends on #12651.
…12651) Some registries (like Azure Artifact) can require you to authenticate separately for every package URL if you do not authenticate for the /simple endpoint. These changes make the auth middleware aware of index URL endpoints and attempts to fetch keyring credentials for such an index URL when making a request to any URL it's a prefix of. The current uv behavior is to cache credentials either at the request URL or realm level. But with these changes, we also need to cache credentials at the index level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Addresses part of #4056 Closes #4583 Closes #11236 Closes #11391 Closes #11507
…ndexes (#12717) The current uv behavior is to cache credentials either at the request URL or realm level. But in general, the expected behavior for indexes is to apply credentials at the index level (as implemented in #12651). This means that we also need to cache credentials at this level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Depends on #12651.
…y on authentication failure (#12805) uv’s default index strategy was designed with dependency confusion attacks in mind. [According to the docs](https://docs.astral.sh/uv/configuration/indexes/#searching-across-multiple-indexes), “if a package exists on an internal index, it should always be installed from the internal index, and never from PyPI”. Unfortunately, this is not true in the case where authentication fails on that internal index. In that case, uv will simply try the next index (even on the `first-index` strategy). This means that uv is not secure by default in this common scenario. This PR causes uv to stop searching for a package if it encounters an authentication failure at an index. It is possible to opt out of this behavior for an index with a new `pyproject.toml` option `ignore-error-codes`. For example: ``` [[tool.uv.index]] name = "my-index" url = "<index-url>" ignore-error-codes = [401, 403] ``` This will also enable users to handle idiosyncratic registries in a more fine-grained way. For example, PyTorch registries return a 403 when a package is not found. In this PR, we special-case PyTorch registries to ignore 403s, but users can use `ignore-error-codes` to handle similar behaviors if they encounter them on internal registries. Depends on #12651 Closes #9429 Closes #12362
…12651) Some registries (like Azure Artifact) can require you to authenticate separately for every package URL if you do not authenticate for the /simple endpoint. These changes make the auth middleware aware of index URL endpoints and attempts to fetch keyring credentials for such an index URL when making a request to any URL it's a prefix of. The current uv behavior is to cache credentials either at the request URL or realm level. But with these changes, we also need to cache credentials at the index level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Addresses part of #4056 Closes #4583 Closes #11236 Closes #11391 Closes #11507
…y on authentication failure (#12805) uv’s default index strategy was designed with dependency confusion attacks in mind. [According to the docs](https://docs.astral.sh/uv/configuration/indexes/#searching-across-multiple-indexes), “if a package exists on an internal index, it should always be installed from the internal index, and never from PyPI”. Unfortunately, this is not true in the case where authentication fails on that internal index. In that case, uv will simply try the next index (even on the `first-index` strategy). This means that uv is not secure by default in this common scenario. This PR causes uv to stop searching for a package if it encounters an authentication failure at an index. It is possible to opt out of this behavior for an index with a new `pyproject.toml` option `ignore-error-codes`. For example: ``` [[tool.uv.index]] name = "my-index" url = "<index-url>" ignore-error-codes = [401, 403] ``` This will also enable users to handle idiosyncratic registries in a more fine-grained way. For example, PyTorch registries return a 403 when a package is not found. In this PR, we special-case PyTorch registries to ignore 403s, but users can use `ignore-error-codes` to handle similar behaviors if they encounter them on internal registries. Depends on #12651 Closes #9429 Closes #12362
…y on authentication failure (#12805) uv’s default index strategy was designed with dependency confusion attacks in mind. [According to the docs](https://docs.astral.sh/uv/configuration/indexes/#searching-across-multiple-indexes), “if a package exists on an internal index, it should always be installed from the internal index, and never from PyPI”. Unfortunately, this is not true in the case where authentication fails on that internal index. In that case, uv will simply try the next index (even on the `first-index` strategy). This means that uv is not secure by default in this common scenario. This PR causes uv to stop searching for a package if it encounters an authentication failure at an index. It is possible to opt out of this behavior for an index with a new `pyproject.toml` option `ignore-error-codes`. For example: ``` [[tool.uv.index]] name = "my-index" url = "<index-url>" ignore-error-codes = [401, 403] ``` This will also enable users to handle idiosyncratic registries in a more fine-grained way. For example, PyTorch registries return a 403 when a package is not found. In this PR, we special-case PyTorch registries to ignore 403s, but users can use `ignore-error-codes` to handle similar behaviors if they encounter them on internal registries. Depends on #12651 Closes #9429 Closes #12362
…12651) Some registries (like Azure Artifact) can require you to authenticate separately for every package URL if you do not authenticate for the /simple endpoint. These changes make the auth middleware aware of index URL endpoints and attempts to fetch keyring credentials for such an index URL when making a request to any URL it's a prefix of. The current uv behavior is to cache credentials either at the request URL or realm level. But with these changes, we also need to cache credentials at the index level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior. Addresses part of #4056 Closes #4583 Closes #11236 Closes #11391 Closes #11507
…y on authentication failure (#12805) uv’s default index strategy was designed with dependency confusion attacks in mind. [According to the docs](https://docs.astral.sh/uv/configuration/indexes/#searching-across-multiple-indexes), “if a package exists on an internal index, it should always be installed from the internal index, and never from PyPI”. Unfortunately, this is not true in the case where authentication fails on that internal index. In that case, uv will simply try the next index (even on the `first-index` strategy). This means that uv is not secure by default in this common scenario. This PR causes uv to stop searching for a package if it encounters an authentication failure at an index. It is possible to opt out of this behavior for an index with a new `pyproject.toml` option `ignore-error-codes`. For example: ``` [[tool.uv.index]] name = "my-index" url = "<index-url>" ignore-error-codes = [401, 403] ``` This will also enable users to handle idiosyncratic registries in a more fine-grained way. For example, PyTorch registries return a 403 when a package is not found. In this PR, we special-case PyTorch registries to ignore 403s, but users can use `ignore-error-codes` to handle similar behaviors if they encounter them on internal registries. Depends on #12651 Closes #9429 Closes #12362
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [astral-sh/uv](https://github.com/astral-sh/uv) | minor | `0.6.16` -> `0.7.3` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (astral-sh/uv)</summary> ### [`v0.7.3`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#073) [Compare Source](astral-sh/uv@0.7.2...0.7.3) ##### Enhancements - Add `--dry-run` support to `uv self update` ([#​9829](astral-sh/uv#9829)) - Add `--show-with` to `uv tool list` to list packages included by `--with` ([#​13264](astral-sh/uv#13264)) - De-duplicate fetched index URLs ([#​13205](astral-sh/uv#13205)) - Support more zip compression formats: bzip2, lzma, xz, zstd ([#​13285](astral-sh/uv#13285)) - Add support for downloading GraalPy ([#​13172](astral-sh/uv#13172)) - Improve error message when a virtual environment Python symlink is broken ([#​12168](astral-sh/uv#12168)) - Use `fs_err` for paths in symlinking errors ([#​13303](astral-sh/uv#13303)) - Minify and embed managed Python JSON at compile time ([#​12967](astral-sh/uv#12967)) ##### Preview features - Build backend: Make preview default and add configuration docs ([#​12804](astral-sh/uv#12804)) - Build backend: Allow escaping in globs ([#​13313](astral-sh/uv#13313)) - Build backend: Make builds reproducible across operating systems ([#​13171](astral-sh/uv#13171)) ##### Configuration - Add `python-downloads-json-url` option for `uv.toml` to configure custom Python installations via JSON URL ([#​12974](astral-sh/uv#12974)) ##### Bug fixes - Check nested IO errors for retries ([#​13260](astral-sh/uv#13260)) - Accept `musllinux_1_0` as a valid platform tag ([#​13289](astral-sh/uv#13289)) - Fix discovery of pre-release managed Python versions in range requests ([#​13330](astral-sh/uv#13330)) - Respect locked script preferences in `uv run --with` ([#​13283](astral-sh/uv#13283)) - Retry streaming downloads on broken pipe errors ([#​13281](astral-sh/uv#13281)) - Treat already-installed base environment packages as preferences in `uv run --with` ([#​13284](astral-sh/uv#13284)) - Avoid enumerating sources in errors for path Python requests ([#​13335](astral-sh/uv#13335)) - Avoid re-creating virtual environment with `--no-sync` ([#​13287](astral-sh/uv#13287)) ##### Documentation - Remove outdated description of index strategy ([#​13326](astral-sh/uv#13326)) - Update "Viewing the version" docs ([#​13241](astral-sh/uv#13241)) ### [`v0.7.2`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#072) [Compare Source](astral-sh/uv@0.7.1...0.7.2) ##### Enhancements - Improve trace log for retryable errors ([#​13228](astral-sh/uv#13228)) - Use "error" instead of "warning" for self-update message ([#​13229](astral-sh/uv#13229)) - Error when `uv version` is used with project-specific flags but no project is found ([#​13203](astral-sh/uv#13203)) ##### Bug fixes - Fix incorrect virtual environment invalidation for pre-release Python versions ([#​13234](astral-sh/uv#13234)) - Fix patching of `clang` in managed Python sysconfig ([#​13237](astral-sh/uv#13237)) - Respect `--project` in `uv version` ([#​13230](astral-sh/uv#13230)) ### [`v0.7.1`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#071) [Compare Source](astral-sh/uv@0.7.0...0.7.1) ##### Enhancement - Add support for BLAKE2b-256 ([#​13204](astral-sh/uv#13204)) ##### Bugfix - Revert fix handling of authentication when encountering redirects ([#​13215](astral-sh/uv#13215)) ### [`v0.7.0`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#070) [Compare Source](astral-sh/uv@0.6.17...0.7.0) This release contains various changes that improve correctness and user experience, but could break some workflows; many changes have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes. ##### Breaking changes - **Update `uv version` to display and update project versions ([#​12349](astral-sh/uv#12349 Previously, `uv version` displayed uv's version. Now, `uv version` will display or update the project's version. This interface was [heavily requested](astral-sh/uv#6298) and, after much consideration, we decided that transitioning the top-level command was the best option. Here's a brief example: ```console $ uv init example Initialized project `example` at `./example` $ cd example $ uv version example 0.1.0 $ uv version --bump major example 0.1.0 => 1.0.0 $ uv version --short 1.0.0 ``` If used outside of a project, uv will fallback to showing its own version still: ```console $ uv version warning: failed to read project: No `pyproject.toml` found in current directory or any parent directory running `uv self version` for compatibility with old `uv version` command. this fallback will be removed soon, pass `--preview` to make this an error. uv 0.7.0 (4433f41c9 2025-04-29) ``` As described in the warning, `--preview` can be used to error instead: ```console $ uv version --preview error: No `pyproject.toml` found in current directory or any parent directory ``` The previous functionality of `uv version` was moved to `uv self version`. - **Avoid fallback to subsequent indexes on authentication failure ([#​12805](astral-sh/uv#12805 When using the `first-index` strategy (the default), uv will stop searching indexes for a package once it is found on a single index. Previously, uv considered a package as "missing" from an index during authentication failures, such as an HTTP 401 or HTTP 403 (normally, missing packages are represented by an HTTP 404). This behavior was motivated by unusual responses from some package indexes, but reduces the safety of uv's index strategy when authentication fails. Now, uv will consider an authentication failure as a stop-point when searching for a package across indexes. The `index.ignore-error-codes` option can be used to recover the existing behavior, e.g.: ```toml [[tool.uv.index]] name = "pytorch" url = "https://download.pytorch.org/whl/cpu" ignore-error-codes = [401, 403] ``` Since PyTorch's indexes always return a HTTP 403 for missing packages, uv special-cases indexes on the `pytorch.org` domain to ignore that error code by default. - **Require the command in `uvx <name>` to be available in the Python environment ([#​11603](astral-sh/uv#11603 Previously, `uvx` would attempt to execute a command even if it was not provided by a Python package. For example, if we presume `foo` is an empty Python package which provides no command, `uvx foo` would invoke the `foo` command on the `PATH` (if present). Now, uv will error early if the `foo` executable is not provided by the requested Python package. This check is not enforced when `--from` is used, so patterns like `uvx --from foo bash -c "..."` are still valid. uv also still allows `uvx foo` where the `foo` executable is provided by a dependency of `foo` instead of `foo` itself, as this is fairly common for packages which depend on a dedicated package for their command-line interface. - **Use index URL instead of package URL for keyring credential lookups ([#​12651](astral-sh/uv#12651 When determining credentials for querying a package URL, uv previously sent the full URL to the `keyring` command. However, some keyring plugins expect to receive the *index URL* (which is usually a parent of the package URL). Now, uv requests credentials for the index URL instead. This behavior matches `pip`. - **Remove `--version` from subcommands ([#​13108](astral-sh/uv#13108 Previously, uv allowed the `--version` flag on arbitrary subcommands, e.g., `uv run --version`. However, the `--version` flag is useful for other operations since uv is a package manager. Consequently, we've removed the `--version` flag from subcommands — it is only available as `uv --version`. - **Omit Python 3.7 downloads from managed versions ([#​13022](astral-sh/uv#13022 Python 3.7 is EOL and not formally supported by uv; however, Python 3.7 was previously available for download on a subset of platforms. - **Reject non-PEP 751 TOML files in install, compile, and export commands ([#​13120](astral-sh/uv#13120), [#​13119](astral-sh/uv#13119 Previously, uv treated arbitrary `.toml` files passed to commands (e.g., `uv pip install -r foo.toml` or `uv pip compile -o foo.toml`) as `requirements.txt`-formatted files. Now, uv will error instead. If using PEP 751 lockfiles, use the standardized format for custom names instead, e.g., `pylock.foo.toml`. - **Ignore arbitrary Python requests in version files ([#​12909](astral-sh/uv#12909 uv allows arbitrary strings to be used for Python version requests, in which they are treated as an executable name to search for in the `PATH`. However, using this form of request in `.python-version` files is non-standard and conflicts with `pyenv-virtualenv` which writes environment names to `.python-version` files. In this release, uv will now ignore requests that are arbitrary strings when found in `.python-version` files. - **Error on unknown dependency object specifiers ([12811](astral-sh/uv#12811 The `[dependency-groups]` entries can include "object specifiers", e.g. `set-phasers-to = ...` in: ```toml [dependency-groups] foo = ["pyparsing"] bar = [{set-phasers-to = "stun"}] ``` However, the only current spec-compliant object specifier is `include-group`. Previously, uv would ignore unknown object specifiers. Now, uv will error. - **Make `--frozen` and `--no-sources` conflicting options ([#​12671](astral-sh/uv#12671 Using `--no-sources` always requires a new resolution and `--frozen` will always fail when used with it. Now, this conflict is encoded in the CLI options for clarity. - **Treat empty `UV_PYTHON_INSTALL_DIR` and `UV_TOOL_DIR` as unset ([#​12907](astral-sh/uv#12907), [#​12905](astral-sh/uv#12905 Previously, these variables were treated as set to the current working directory when set to an empty string. Now, uv will ignore these variables when empty. This matches uv's behavior for other environment variables which configure directories. ##### Enhancements - Disallow mixing requirements across PyTorch indexes ([#​13179](astral-sh/uv#13179)) - Add optional managed Python archive download cache ([#​12175](astral-sh/uv#12175)) - Add `poetry-core` as a `uv init` build backend option ([#​12781](astral-sh/uv#12781)) - Show tag hints when failing to find a compatible wheel in `pylock.toml` ([#​13136](astral-sh/uv#13136)) - Report Python versions in `pyvenv.cfg` version mismatch ([#​13027](astral-sh/uv#13027)) ##### Bug fixes - Avoid erroring on omitted wheel-only packages in `pylock.toml` ([#​13132](astral-sh/uv#13132)) - Fix display name for `uvx --version` ([#​13109](astral-sh/uv#13109)) - Restore handling of authentication when encountering redirects ([#​13050](astral-sh/uv#13050)) - Respect build options (`--no-binary` et al) in `pylock.toml` ([#​13134](astral-sh/uv#13134)) - Use `upload-time` rather than `upload_time` in `uv.lock` ([#​13176](astral-sh/uv#13176)) ##### Documentation - Changed `fish` completions append `>>` to overwrite `>` ([#​13130](astral-sh/uv#13130)) - Add `pylock.toml` mentions where relevant ([#​13115](astral-sh/uv#13115)) - Add ROCm example to the PyTorch guide ([#​13200](astral-sh/uv#13200)) - Upgrade PyTorch guide to CUDA 12.8 and PyTorch 2.7 ([#​13199](astral-sh/uv#13199)) ### [`v0.6.17`](https://github.com/astral-sh/uv/releases/tag/0.6.17) [Compare Source](astral-sh/uv@0.6.16...0.6.17) #### Release Notes ##### Preview features - Add PyTorch v2.7.0 to GPU backend ([#​13072](astral-sh/uv#13072)) ##### Bug fixes - Avoid panic for invalid Python versions ([#​13077](astral-sh/uv#13077)) - Block scripts from overwriting `python` ([#​13051](astral-sh/uv#13051)) - Check distribution names to handle invalid redirects ([#​12917](astral-sh/uv#12917)) - Check for mismatched package and distribution names on resolver thread ([#​13088](astral-sh/uv#13088)) - Fix panic with invalid last character in PEP 508 name ([#​13105](astral-sh/uv#13105)) - Reject `requires-python` even if not listed on the index page ([#​13086](astral-sh/uv#13086)) #### Install uv 0.6.17 ##### Install prebuilt binaries via shell script ```sh curl --proto '=https' --tlsv1.2 -LsSf https://github.com/astral-sh/uv/releases/download/0.6.17/uv-installer.sh | sh ``` ##### Install prebuilt binaries via powershell script ```sh powershell -ExecutionPolicy Bypass -c "irm https://github.com/astral-sh/uv/releases/download/0.6.17/uv-installer.ps1 | iex" ``` #### Download uv 0.6.17 | File | Platform | Checksum | |--------|----------|----------| | [uv-aarch64-apple-darwin.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-apple-darwin.tar.gz) | Apple Silicon macOS | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-apple-darwin.tar.gz.sha256) | | [uv-x86\_64-apple-darwin.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-apple-darwin.tar.gz) | Intel macOS | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-apple-darwin.tar.gz.sha256) | | [uv-aarch64-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-pc-windows-msvc.zip) | ARM64 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-pc-windows-msvc.zip.sha256) | | [uv-i686-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-pc-windows-msvc.zip) | x86 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-pc-windows-msvc.zip.sha256) | | [uv-x86\_64-pc-windows-msvc.zip](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-pc-windows-msvc.zip) | x64 Windows | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-pc-windows-msvc.zip.sha256) | | [uv-aarch64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-gnu.tar.gz) | ARM64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-gnu.tar.gz.sha256) | | [uv-i686-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-gnu.tar.gz) | x86 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-gnu.tar.gz.sha256) | | [uv-powerpc64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64-unknown-linux-gnu.tar.gz) | PPC64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64-unknown-linux-gnu.tar.gz.sha256) | | [uv-powerpc64le-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64le-unknown-linux-gnu.tar.gz) | PPC64LE Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-powerpc64le-unknown-linux-gnu.tar.gz.sha256) | | [uv-s390x-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-s390x-unknown-linux-gnu.tar.gz) | S390x Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-s390x-unknown-linux-gnu.tar.gz.sha256) | | [uv-x86\_64-unknown-linux-gnu.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-gnu.tar.gz) | x64 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-gnu.tar.gz.sha256) | | [uv-armv7-unknown-linux-gnueabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-gnueabihf.tar.gz) | ARMv7 Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-gnueabihf.tar.gz.sha256) | | [uv-aarch64-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-musl.tar.gz) | ARM64 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-aarch64-unknown-linux-musl.tar.gz.sha256) | | [uv-i686-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-musl.tar.gz) | x86 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-i686-unknown-linux-musl.tar.gz.sha256) | | [uv-x86\_64-unknown-linux-musl.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-musl.tar.gz) | x64 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-x86\_64-unknown-linux-musl.tar.gz.sha256) | | [uv-arm-unknown-linux-musleabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-arm-unknown-linux-musleabihf.tar.gz) | ARMv6 MUSL Linux (Hardfloat) | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-arm-unknown-linux-musleabihf.tar.gz.sha256) | | [uv-armv7-unknown-linux-musleabihf.tar.gz](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-musleabihf.tar.gz) | ARMv7 MUSL Linux | [checksum](https://github.com/astral-sh/uv/releases/download/0.6.17/uv-armv7-unknown-linux-musleabihf.tar.gz.sha256) | </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yNTcuOCIsInVwZGF0ZWRJblZlciI6IjM5LjI2NC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Some registries (like Azure Artifact) can require you to authenticate separately for every package URL if you do not authenticate for the /simple endpoint. These changes make the auth middleware aware of index URL endpoints and attempts to fetch keyring credentials for such an index URL when making a request to any URL it's a prefix of.
The current uv behavior is to cache credentials either at the request URL or realm level. But with these changes, we also need to cache credentials at the index level. Note that when uv does not detect an index URL for a request URL, it will continue to apply the old behavior.
Addresses part of #4056
Closes #4583
Closes #11236
Closes #11391
Closes #11507