Skip to content

Downloads Hashing Command Line and Requirements File #468

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

Closed
dstufft opened this issue Mar 2, 2012 · 12 comments
Closed

Downloads Hashing Command Line and Requirements File #468

dstufft opened this issue Mar 2, 2012 · 12 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@dstufft
Copy link
Member

dstufft commented Mar 2, 2012

It is my understanding that pip is supposed to check the passed in hash if it is included in either the requirements file or the command line. This appears to not be currently happening.

These all succeed:

pip install -r requirements.txt # With a randomly typed hash

pip install http://..#md5=random

@carljm
Copy link
Contributor

carljm commented Mar 2, 2012

Confirmed that this is an issue; pull request welcome.

@acdha
Copy link

acdha commented Mar 12, 2012

https://github.com/acdha/pip/tree/issue-468-url-hash-fragment-support has a very simple fix for the second case. This does not work for non-URL installs (e.g. pip install "pkg#md5=wtf") which is probably correct but should trigger an error indicating that the specified value is being ignored in favor of whatever PyPI says.

@jezdez
Copy link
Member

jezdez commented May 4, 2012

FWIW, it's suppose to check the hashes from links it finds on PyPI, not passed from the command line AFAIK.

@acdha
Copy link

acdha commented May 4, 2012

@jezdez What about non-PyPI packages? I was thinking that this would be a great way to have people who need / want to use packages which aren't on PyPI (e.g. Github tarballs, internal repos) to have a backup which isn't insecure

@carljm
Copy link
Contributor

carljm commented May 4, 2012

Right, I think this is really a new feature, not a bug, since it's never been documented that you can do this. But that doesn't really matter - it's a very useful feature with no downside that I can see.

@d1b
Copy link
Contributor

d1b commented Nov 23, 2012

@carljm rubbish this feature is hinted at in the pip documentation (I would consider this a bug not a new feature): from http://www.pip-installer.org/en/latest/usage.html#package-checksum-hashes , "PyPI provides a md5 hash of a package by having the link to the package include a #md5=. pip supports this, as well as any of the guaranteed hashlib algorithms (sha1, sha224, sha384, sha256, sha512, md5)."

@pnasrat
Copy link
Contributor

pnasrat commented Nov 23, 2012

@dstufft has done recent work on this. Any comments Donald?

@pnasrat
Copy link
Contributor

pnasrat commented Nov 23, 2012

@d1b have you tested with latest pip or develop branch?

@qwcode
Copy link
Contributor

qwcode commented Nov 24, 2012

it's reasonable to want pip install http://..somepackage.tar.gz#md5=HASH to check the hash,
but I'm not sure what this means from the description pip install -r requirements.txt # With a randomly typed hash
there's a url requirement in the requierments file with a random hash tacked onto to it?

@d1b
Copy link
Contributor

d1b commented Nov 24, 2012

@pnasrat are you suggesting that this bug has been fixed in pip already? It certainly appears not to have been fixed -->

~/.local/bin/pip install http://localhost:4344/archive.zip#md5=123
Downloading/unpacking http://localhost:4344/archive.zip
Downloading archive.zip
Running setup.py egg_info for package from http://localhost:4344/archive.zip

@d1b
Copy link
Contributor

d1b commented Nov 24, 2012

@qwcode I believe @dstufft meant to suggest that the requirements.txt file contained a line like 'http://..#md5=random' (a hash for an individual entry not for the whole file).

@dstufft
Copy link
Member Author

dstufft commented Dec 14, 2016

This is more or less solved with pep 8's explicit hash checking mode.

@dstufft dstufft closed this as completed Dec 14, 2016
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

No branches or pull requests

7 participants