Feature Proposal - Dependency Confusion Warning

[davidus27]

In pip there is a known possibility for dependency confusion attack. There were discussions in pip about solving this problem by removing potentially dangerous flag --extra-index-url or returning an error on install.

AFAIK there wasn't any real fix or alternation of this vulnerability. Your tool might be an ideal for solving this problem.

Proposed feature:

• In case when two different registry urls are provided as arguments by using --extra-index-url the tool could raise an warning about dangerous configuration.

• On top of that, in case when it installs the version from alternative registry with bigger package version (red flag for possible attack) it might warn the developer for possible dependency confusion attack.

[feynmanix]

Hi @davidus27, yes, this is a relevant concern indeed.

I tend to defer to pip with their decision not to deprecate (show warning) for the --extra-index-url option.
For the record, uv kept the --extra-index-url flag but changed its (default) semantic. Also, this should be addressed by pinning the source of the dependency - e.g., poetry can do this with internal-package = {version = "^1.0.0", source = "private"} syntax, and lock files should pin the source too, though if we could rely on people using that correctly, we wouldn't need pipask...

If the user uses one of the index options, I'm assuming they know what they are doing in that they really want to use multiple indexes. The real danger is if someone publishes a malicious package to a default (public) registry that's only expected to be in a private one. This would result in installation of the malicious version if:

1. package is in both, higher version found in the public registry
2. package is in both but the local registry is not available, e.g., due to network issues
3. package somehow disappeared from the local registry so only the public one is available

Case 1 should be easy to detect, is definitely suspicious and printing a strong warning makes sense as a pipask feature.

I'd like to dig deeper into case 2 - I'm not sure how difficult it would be to detect this and add a warning, but it makes sense as a feature too.

Case 3 is hard to detect and I hope sufficiently rare, so I think I'll just ignore it for now.