Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Support dependency hashing #716

Open
bigjools opened this issue Jan 18, 2023 · 4 comments
Open

Feature request: Support dependency hashing #716

bigjools opened this issue Jan 18, 2023 · 4 comments

Comments

@bigjools
Copy link

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
Copy link
Contributor

Bobronium commented Jan 25, 2023

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
Copy link

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
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants