

Peep: A "pip install" that is cryptographically guaranteed repeatable - grincho
https://pypi.python.org/pypi/peep/

======
grincho
I also found something comparable for npm this afternoon, after much
searching: [https://github.com/mozilla/npm-
lockdown](https://github.com/mozilla/npm-lockdown).

------
jace
I like it. I'm going to switch.

------
cbcunc
Should be an option for pip itself.

~~~
grincho
That's the long-term plan, but it's hung up in bikeshedding for now:
[https://github.com/pypa/pip/issues/1175](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. :-)

------
officialjunk
is the requirements.txt not vulnerable to be altered?

~~~
grincho
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.

