Peep: A "pip install" that is cryptographically guaranteed repeatable(pypi.python.org)
pypi.python.org
Peep: A "pip install" that is cryptographically guaranteed repeatable
https://pypi.python.org/pypi/peep/
4 comments
I also found something comparable for npm this afternoon, after much searching: https://github.com/mozilla/npm-lockdown.
I like it. I'm going to switch.
Should be an option for pip itself.
That's the long-term plan, but it's hung up in bikeshedding for now: https://github.com/pypa/pip/issues/1175. My faith in our ability to do it soon is evidenced by my release of a new feature release of peep yesterday. :-)
is the requirements.txt not vulnerable to be altered?
Use of peep is based on a chain of trust. How do you trust your source code in the first place? That's how you trust your requirements file.
As for how you arrange that trust, comparison of git hashes with a test-passing build on your CI server is one candidate. Your CI server fetches the code over HTTPS, which can be trusted to the degree you trust your key management and the network between your CI and the repo. If you don't trust certificate authorities, pin your certs. You might also factor in a comparison with a hash from a developer's machine, submitted separately to the CI server, perhaps even signed with a personal key.
If git hashes are part of your chain of trust, don't forget to have your deployment script run "git fsck" after checkout—git doesn't verify hashes on checkout by default. You can demonstrate this to yourself by editing the contents of one of the files in .git and then checking it out.
As for how you arrange that trust, comparison of git hashes with a test-passing build on your CI server is one candidate. Your CI server fetches the code over HTTPS, which can be trusted to the degree you trust your key management and the network between your CI and the repo. If you don't trust certificate authorities, pin your certs. You might also factor in a comparison with a hash from a developer's machine, submitted separately to the CI server, perhaps even signed with a personal key.
If git hashes are part of your chain of trust, don't forget to have your deployment script run "git fsck" after checkout—git doesn't verify hashes on checkout by default. You can demonstrate this to yourself by editing the contents of one of the files in .git and then checking it out.