[Cryptography-dev] Verifying our History by Signing Commits

[Donald Stufft]

So Jean-Paul brought up in #cryptography-dev about the idea of signing our
git commits.

Personally I think this is a good idea however if we want to do it it leaves
a few open questions with how we do it.

Ideally the person who is adding the commit to the repository is the person
who signs the commit (think of it similarly to the Signed-Off line). They are
claiming responsibility for the commit landing in the tree. 

So the questions are

1) Do we want to have a policy of requiring GPG signed commits?

2) Do we want to require every commit being signed (which means reviewing
   every commit of a PR and signing it) or do we just want to require signing
   of the merge commit?

3) How does this interact with our code review process? Obviously if someone
   not a maintainer makes a patch whichever one of us commits it will be the
   signer, does the same follow for code written by us?

This will likely require additional infrastructure to check every commit that
lands on master is signed by a trusted key however a single Jenkins server
should be plenty to ensure that everything is signed.

Some additional reading: http://mikegerwitz.com/papers/git-horror-story.html

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20130808/394c10b9/attachment.pgp>