Make `requirements.txt` version constraints identical to hash constraints.
Currently the requirements.txt
for Ooni has lines like this:
Twisted>=12.2.0
#https://pypi.python.org/packages/source/T/Twisted/Twisted-13.0.0.tar.bz2#md5=68afff4e1efd3757d934e39f70c99f57#egg=Twisted
If the first quoted line is fulfilled, many different versions may be installed, including 14.0
. If the second quoted line is fulfilled then only a very specific (as per md5
) dependency is used.
If users neglect to tell the error prone and confusing python packaging ecosystem tools to respect the second line, and those tools only rely on the first version constraint, the result has two problems:
- The process is likely to be vulnerable to an interception attack where the attacker replaces the to-be-installed dependency with code of their choice, and
- The process, even when not attacked, will install an unsupported dependency version.
A simple way to fix the second item without addressing the security vulnerability is to ensure the version constraints match the secure specifications. So the above snippet would be rewritten as:
twisted==13.0.0
#https://pypi.python.org/packages/source/T/Twisted/Twisted-13.0.0.tar.bz2#md5=68afff4e1efd3757d934e39f70c99f57#egg=Twisted
Then in a nice happy world where there are not meanies injecting malicious code into the install process, the vulnerable users will not encounter functional bugs based on version skew.
Maybe it's a bad idea to cater to a vulnerable install, but something about the inconsistency here rubs me the wrong way.
Trac:
Username: nathan-at-least