In light of recent articles about package managers preferring higher version packages.
The exploit path is essentially this:
- An organisation creates a custom python library with a certain version
- The org places the library in a requirements file with a relaxed or no version spec, along with a mixture of modules available in pypi
- Someone comes and squats on their custom python library in pypi, with a higher version
- pip will then install the squatted library from pypi, as pip prefers newer versions
We actually talked about this very problem here:
If the version in svn is later than any on PyPI, it will be picked. if not, it won’t. If the latest version on PyPI is the same as the version number in svn, then either can be picked, but they should be identical (because that’s what having the same version number means) and so why would you care?
If you want to pick the version in svn in preference to those on PyPI, give it a higher version number.
Only in this ticket, we’re just talking about svn.
I suppose we can say that orgs have a responsiblity to pin their version numbers, but I think this warrants a discussion about what our defaults are.
One of suggestions in the linked issue is to use
--no-index but that requires splitting requirements into things that are internal and public. This may be fine, but at least we should note and document it somewhere as a special use case.