Implement --index-strategy to mitigate dependency confusion (#8606)

[Ashutosh0x]

This PR implements the --index-strategy feature to mitigate dependency confusion attacks, addressing #8606.

Summary

--index-strategy: Controls how pip selects packages from multiple indexes.

• best-match (default): Standard pip behavior. Searches all indexes for the highest version.
• first-match: Prioritizes indexes in the order they are provided (--index-url then --extra-index-url). The search stops at the first index that yields a match.

Motivation

The current "Version Priority" behavior exposes users to Dependency Confusion attacks. An attacker can upload a higher version of a private package name to a public repository, and pip will prioritize it. This feature provides a mechanism for users to enforce index isolation by stopping the search once a match is found.

Design Details

• Priority Order: find-links are collected first. Then, we iterate through --index-url and --extra-index-url in order.
• Stopping: In first-match mode, the search stops as soon as one index URL returns candidates.

[Ashutosh0x]

pre-commit.ci autofix

[notatallshaw]

Hi @Ashutosh0x thanks for the PR, please be aware reviews can be quite slow due to maintainers only being able to volunteer their spare time to pip.

That said, I would like you to explicitly explain the design here:

1. What is the intended priority between index-url,extra-index-url, and --find-links options?
2. Does this match uv's behavior (https://docs.astral.sh/uv/concepts/indexes/#-index-url-and-extra-index-url)?
3. When multiple links are specified for find-links and multiple index urls expecified for extra-index-url what is the intended priority direction?
4. Is there a specific index-strategy from uv this matches (https://docs.astral.sh/uv/reference/cli/#uv-pip-compile--index-strategy)?

To be clear you don't have to match uv, but given it's set a precedent it should be understood if not why not.

If the design is agreed on there will need to be at least an update to the user guide, as well as unit and functional tests.

I also think I prefer uv's choice of have an option that can take different values, rather than a boolean, this will allow users to explicitly choose new or old behavior, add new options in the future, and potentially change the default.

P.S The Windows failures for Run winget install --accept-source-agreements --accept-package-agreements -e --id Slik.Subversion is unrelated to this PR, I will try and fix it in a different PR when I have time.

[Ashutosh0x]

Thanks for the review @notatallshaw!

Regarding the design questions:

1. Priority Order: In the current implementation, find-links are always collected first (aggregating all of them, as they are often used for supplementary artifacts). Then, we iterate through --index-url and --extra-index-url sequences in order. We stop searching indexes as soon as one index URL returns candidates. The final candidate list is a combination of everything found in --find-links plus the first successful index.

   • Direction: find-links (all) -> index-url -> extra-index-url (first match stops).

2. UV Comparison: This aims to mimic uv's unsafe-first-match strategy where it respects the order of index definition.

3. Boolean vs Strategy: I completely agree. Migrating to an --index-strategy option (enum) is much more robust and future-proof than a simple boolean. It allows us to support first-match now and potential other strategies later without polluting the namespace.

Plan:
I will update this PR to:

1. Replace --index-priority with --index-strategy.
2. Support values like best-match (default, legacy behavior) and first-match (new isolated behavior).
3. Add proper documentation on how this interacts with find-links.

I'll push these changes shortly!

[notatallshaw]

--index-strategy and --index-mapping seem to be two separate features, they should not be in the same PR, break it out into a separate PR. In the new PR describe the design of your feature so we can evaluate it and the implementation.

Also, for --index-mapping if the request doesn't already exist create one, so there is a place to discuss if this is a worthwhile feature or if there are any important design considerations, and the PR can be focused on the implementation.

[notatallshaw]

Please don't make changes to the repo's .gitignore, if you need to git ignore local files you should create your own user level git ignore, e.g. https://dev.to/fronkan/a-personal-gitignore-even-for-a-single-repository-4o7h