requirement, pypi: Add a --require-hashes flag

[tetsuo-cpp]

Closes #172

• Bump pip-api version
• Needs: pip_api: initial support for hashed requirements di/pip-api#126

[tetsuo-cpp]

This needs cleanup + testing + doc but I wanted to engage early on this one since the intended behaviour isn't straightforward.

@di You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve transitive dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?

I was also wondering how hashes should work when the --require-hashes flag isn't supplied. My thinking is that when the --require-hashes flag is supplied, every requirement in the file needs to have a hash AND we check them against PyPI. But if the flag isn't supplied, we should still check any hashes that we find against PyPI and fail if it doesn't match.

[woodruffw]

You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve transitive dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?

I was also wondering how hashes should work when the --require-hashes flag isn't supplied. My thinking is that when the --require-hashes flag is supplied, every requirement in the file needs to have a hash AND we check them against PyPI. But if the flag isn't supplied, we should still check any hashes that we find against PyPI and fail if it doesn't match.

This is an indirect answer to both: we can skip dependency resolution entirely, since pip stipulates the following:

1. If any dependency has a content hash, then all dependencies have content hashes
2. (Transitively) All dependencies must be explicitly listed in the requirements file if hashing is enabled

In other words: our requirements parser in pip-api should preserve those properties: we should raise an error if we're given a requirements file with dependencies that are missing hashes, and we should not do dependency resolution because only the present hashed dependencies should be considered.

(Looking at things more, I'm not actually sure that we need the --require-hashes flag -- pip stipulates that passing it is identical to any requirement having hashes attached to it. But I guess we should preserve it as a no-op, since that's what pip seems to do?

[tetsuo-cpp]

In other words: our requirements parser in pip-api should preserve those properties: we should raise an error if we're given a requirements file with dependencies that are missing hashes, and we should not do dependency resolution because only the present hashed dependencies should be considered.

Ah! Right, I misunderstood the pip behaviour. Thanks for explaining.

(Looking at things more, I'm not actually sure that we need the --require-hashes flag -- pip stipulates that passing it is identical to any requirement having hashes attached to it. But I guess we should preserve it as a no-op, since that's what pip seems to do?

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

[woodruffw]

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

Ah! You're absolutely right. Yes, we need it for that case.

[di]

@di You mentioned that the --require-hashes flag should skip dependency resolution. Did you mean that we shouldn't resolve transitive dependencies for each requirement and instead, only audit what is explicitly listed in the requirements file?

Thinking about this more, I think we still need to do dependency resolution, and ensure that we have hashes for all subdependencies, because this is what pip does as well:

$ cat req.txt
sampleproject==2.0.0 \
    --hash=sha256:2b0c55537193b792098977fdb62f0acbaeb2c3cfc56d0e24ccab775201462e04 \
    --hash=sha256:d99de34ffae5515db43916ec47380d3c603e9dead526f96581b48c070cc816d3

$ python -m pip install -r req.txt
Collecting sampleproject==2.0.0 (from -r req.txt (line 1))
  Using cached https://files.pythonhosted.org/packages/b8/f7/dd9223b39f683690c30f759c876df0944815e47b588cb517e4b9e652bcf7/sampleproject-2.0.0-py3-none-any.whl
Collecting peppercorn (from sampleproject==2.0.0->-r req.txt (line 1))
ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    peppercorn from https://files.pythonhosted.org/packages/14/84/d8d9c3f17bda2b6f49406982546d6f6bc0fa188a43d4e3ba9169a457ee04/peppercorn-0.6-py3-none-any.whl#sha256=46125cad688a9cf3b08e463bcb797891ee73ece93602a8ea6f14e40d1042d454 (from sampleproject==2.0.0->-r req.txt (line 1))

I think it's still important because your file may not have ANY hashes in it. If you pass in --require-hashes, it will complain whereas it otherwise would succeed.

Agreed!

[tetsuo-cpp]

Thinking about this more, I think we still need to do dependency resolution, and ensure that we have hashes for all subdependencies, because this is what pip does as well:

Can we leave that validation to pip and not attempt to do it ourselves? I imagine that's going to introduce a significant chunk of code reinventing what pip does which will have to be removed during integration, since pip already contains this logic.

[woodruffw]

Can we leave that validation to pip and not attempt to do it ourselves? I imagine that's going to introduce a significant chunk of code reinventing what pip does which will have to be removed during integration, since pip already contains this logic.

I'm inclined to agree with this, although it does deviate our handling of --require-hashes from that of pip (our --require-hashes is more like --no-deps --require-hashes). My reasoning is that pip-audit isn't in the business of telling the user whether pip install ... would succeed, and that the overwhelming majority of hashed requirements files should be valid already (since, if they're like Warehouse's, they're checked in after successful local and CI usage).

Thoughts @di?

[woodruffw]

Overall structure LGTM here!

[di]

I suppose the pip install with an incompletely hashed requirements file, or a hashed requirements file that's missing dependencies, would fail to install anyways, so the user would be protected regardless.