Description
Currently, coverage.py has requirements/*.pip files that include hashes:
astroid==2.15.0 \
--hash=sha256:525f126d5dc1b8b0b6ee398b33159105615d92dc4a17f2cd064125d57f6186fa \
--hash=sha256:e3e4d0ffc2d15d954065579689c36aac57a339a4679a679579af6401db4d3fdb
# via pylint
attrs==22.2.0 \
--hash=sha256:29e95c7f6778868dbd49170f98f8818f78f3dc5e0e37c0b1f474e3561b240836 \
--hash=sha256:c9227bfc2f01993c03f68db37d1d15c9690188323c067c641f1a35ca58185f99
# via
# hypothesis
# pytest
# etc...
This is meant to increase security by ensuring that the package you get is really the package you wanted, by checking the hash of the downloaded package. But coverage.py doesn't need these hashes, and they causes problems.
Coverage.py is a developer tool, it doesn't run in public-facing production environments. Further, it has no runtime dependencies. Installing coverage doesn't pull in any third-party libraries. These hashes only apply to the developer tools that maintainers and modifiers of coverage install in their local machines or their continuous integration.
The problems arise because the exact set of dependencies installed on a machine varies depending on the OS and the Python version. The .pip files are created by pip-tools on my Mac running Python 3.7. If a contributor tries to install them on Windows running 3.10 (for example), conditional dependencies in third-party libraries will try to pull in a package that wasn't needed on Mac 3.7. That package will not have a hash in the .pip files, and the installation will fail. The solution is then to use the .in files directly, which have no hashes, so what have we gained other than a confusing speed bump for contributors?
The OpenSSF scorecard awards points for hashed pins, but does not distinguish between production and development dependencies. This simplistic gamification shouldn't push us towards making the project unfriendly to contributors.