6 ms·

Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can y

Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct

nightpool 15d ago
The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.
- brewmarche 15d ago
  One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes. We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
  - nightpool 15d ago
    One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.
    - deleted 15d ago
      [deleted]

nightpool 15d ago

The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.

brewmarche 15d ago
One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes. We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.
- nightpool 15d ago
  One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.
  - deleted 15d ago
    [deleted]