4 ms·

I would love to hear your thoughts on the problems with signing every commit. To be honest, I'm surprised it didn't make the initial level 1 -> 4 list since git

by er4hn 5y ago

I would love to hear your thoughts on the problems with signing every commit. To be honest, I'm surprised it didn't make the initial level 1 -> 4 list since git gets you a lot of the way there. In my own employers threat model that ranked pretty highly and I wrote about our own experiences here: https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ https://eos.arista.com/commit-signing-with-git-at-enterprise... . With perspective I would say that the biggest thing I would add onto this is support for RFC 3161 style signed timestamps to the commit, but otherwise this solves a major issue.

dlor 5y ago
You're pretty much spot on. The problem is less about signing and more about existing PKI for git commit signing. We're working with David Huseby to help refactor the way gpg is coupled with git to enable stronger/different PKIs: https://github.com/TrustFrame/git-cryptography-protocol https://github.com/TrustFrame/git-cryptography-protocol I always personally struggle to recommend signing when it's so hard to do correctly. Until there's actually something workable, that supports time-stamping like you mentioned it seems like a false sense of security at best.
- er4hn 5y ago
  Thanks for sharing this. This is very interesting and I did not know about it. I'll make a note to read it and see if there are any useful contributions I can make.
thayne 5y ago
One big problem is how to deal with a key getting revoked. That means every commit signed with that key is no longer valid. As I understand it, re-signing the commits requires rewriting git history, and would probably be a huge pain even if it didn't.
- er4hn 5y ago
  That's what having a trustworthy timestamp solves. A key is revoked at a known time, so being able to know if a commit was signed before or after the time of revocation lets you know what the key to use to validate should be. If you don't have trusted timestamps it is a little harder to trust the git commit timestamps. Those can be altered and you need to add additional checks like comparing with what your code review service says (which can be altered..) or requiring that timestamps increase for each commit (which has edge cases..)

by er4hn 5y ago

dlor 5y ago

You're pretty much spot on. The problem is less about signing and more about existing PKI for git commit signing. We're working with David Huseby to help refactor the way gpg is coupled with git to enable stronger/different PKIs: https://github.com/TrustFrame/git-cryptography-protocol https://github.com/TrustFrame/git-cryptography-protocol I always personally struggle to recommend signing when it's so hard to do correctly. Until there's actually something workable, that supports time-stamping like you mentioned it seems like a false sense of security at best.

er4hn 5y ago
Thanks for sharing this. This is very interesting and I did not know about it. I'll make a note to read it and see if there are any useful contributions I can make.

thayne 5y ago

One big problem is how to deal with a key getting revoked. That means every commit signed with that key is no longer valid. As I understand it, re-signing the commits requires rewriting git history, and would probably be a huge pain even if it didn't.

er4hn 5y ago
That's what having a trustworthy timestamp solves. A key is revoked at a known time, so being able to know if a commit was signed before or after the time of revocation lets you know what the key to use to validate should be. If you don't have trusted timestamps it is a little harder to trust the git commit timestamps. Those can be altered and you need to add additional checks like comparing with what your code review service says (which can be altered..) or requiring that timestamps increase for each commit (which has edge cases..)