Feature request: Support dependency hashing

[bigjools]

Given the focus on supply chain hardening these days, I was a little surprised to see that Hatch doesn't support dependency hashing.

Requirements files with hashes (generated by pip-compile in this case) typically take the form:

alembic==1.9.1 \
    --hash=sha256:a9781ed0979a20341c2cbb56bd22bd8db4fc1913f955e705444bd3a97c59fa32 \
    --hash=sha256:f9f76e41061f5ebe27d4fe92600df9dd612521a7683f904dab328ba02cffa5a2

I only just started investigating Hatch so I have no idea how this could work in practice. I filed a similar bug on hatch-requirements-txt as ideally I want to read the contents of requirements files that are generated by pip-compile, but that could/would be difficult in this project without the above plugin.

[Bobronium]

You might want to look at https://github.com/sbidoul/hatch-pip-deepfreeze

Reading through the plugin source code, I can see that developing a plugin for hatch is kind of a breeze, so it seems like wouldn't take much to write similar plugin for pip-compile, which supports hashes.

And I assume the only reason hatch doesn't have this functionality built-in in the first place is a desire to wait for official support for .lock files in PEP.

See also: https://hatch.pypa.io/latest/meta/faq/#libraries-vs-applications

[ddneilson]

It's not quite as easy as it appears based on the dive into the code that I did the other day. Hatch is using from packaging.requirements import Requirement internally to decode requirements strings. That Requirements module strictly adheres to PEP 508, and unfortunately hashes are not a part of PEP 508 -- they're a de-facto standard that only exists in pip's custom parser for requirements strings. Any Hatch plugin that interacts with requirements strings needs to ensure that Hatch is provided PEP 508 -compatible strings.

A purpose of hashing requirements is to protect a build system from a specific type of supply chain attack -- one where the upstream repository is compromised and a package has been replaced on the server. Unfortunately, pip-deepfreeze doesn't protect against that -- it only protects against a supply chain attack where the attacker compromises the publishing pipeline of a package and publishes a new, compromised, version.

[Bobronium]

Thanks for extended explanation and motivation.

That Requirements module strictly adheres to PEP 508, and unfortunately hashes are not a part of PEP 508

That's a revelation for me. Well, then I guess it indeed needs handling on hatchs side.

Btw, pypa/pip#10748 that docs reference to is now closed and --report is available in latest pip.

Does this mean there's no blockers for locking feature then?

[bigjools]

Hatch is using from packaging.requirements import Requirement internally to decode requirements strings. That Requirements module strictly adheres to PEP 508, and unfortunately hashes are not a part of PEP 508 -- they're a de-facto standard that only exists in pip's custom parser for requirements strings.

I should have been more specific in my original description, but this basically nails it. Thanks :)

I have been working around things for now by using pip-compile and pointing it at pyproject.toml and then running pip install -U --no-deps -r requirements.txt in my Hatch environment.