Ask HN: What should happen to your signed Git commits if you revoke the GPG key?
Hey there!
So imagine that you have been doing a lot of open source coding, and pushing signed commits with GPG over the last couple of years. Some of the commits landing in security-critical projects. Then one day your laptop gets stolen or something, and your GPG private key gets compromised. The proper way to deal with this is to immediately revoke your key, and notify the various Internet key servers that your key has been revoked.
The interesting question - what to do with your old commits that have been verified by the compromised key? At the moment, GitHub marks all your old commits as unverified. Even if you upload a new key (suppose that your master private key is still safe, and you generate a new subkey), GitHub still does not re-verify your old commits. Is this sane?
What about the security-critical projects? All of a sudden they are full of unverified commits in their git history. What should be done about this? Is this a valid attack vector - having commits in Git history which are signed with a revoked GPG key?
I know for a fact that some projects have strict policy of accepting only signed commits. What do they do when a key is revoked? It's not like they can just rip out all that old code from their code tree or something...
--- PS: Interesting discussion on this very same issue at GitHub https://github.com/isaacs/github/issues/1099 .
One thing to note here, is that key revocation is a normal and expected part of a keys life cycle.
Maybe you roll your keys every two or five years? Some would argue that you should.
When you retire an old key, it's not uncommon to revoke the old key. You could let it expire, but you could also publish a revocation cert for it, provide a reason, and maybe mention the new key.
Another issue is that while signing commits can be good, it's not the primary basis for access control to the repository. If your key is compromised, what about the SSH key used to push to it?
Things get fairly complex, when you run into situations like Alice signing her commits, later revoking her key because it got compromised, but then her collegue - Bob - force-pushes a branch, resets the repo entirely, or similar. Then Bob is pushing Alices commits, that were signed by a no longer valid key.
I think a reasonably safe approach would be to say that:
1. Signed commits are viewed as trusted at the time they were first seen, providing the key is not revoked at that point.
2. Compromised keys may need to lead to an audit/damage control, at which point the signature is effectively degraded to a tool towards that end. If the key is revoked due to compromise, and the time of the compromise is unknown, you effectively can't depend on those signatures at all.
So are signed commits worth anything at all then?
I think so. Git is inherently a distributed thing, and I think signed commits can add verification that goes beyond the SSH-access to github or similar.
People also potentially treat their ssh keys and code signing keys differently. Maybe they just reuse one set of ssh keys for everything, keeping it loaded in an ssh agent at all times, key-forwarding it all over the place, but unlock their gpg keys only when signing.
In short: I think signed commits are useful despite possibly running into issues when keys are revoked, but I think it's important to consider what a valid signature provides at different times and in different circumstances.
Sorry for the wall of text, just random things to consider.
Interesting - I have not thought about such scenarios earlier. I think that if you remove your key from GitHub, old commits should be left in place. The various key servers on the Internet will acknowledge the revoked key, and no more new commits will be introduced with that key. However, there is a potential issue when an attacker will try to rewrite Git history and use your old key to sign malicious code.
undefined
IMHO old commits (before key was compromised/revoked) should be considered valid. But that raises another question - WHEN exactly(what date) should be used as a boundary (good commits vs bad commits).
Let's say until I revoked my key on 10Jan, laptop might have been stolen on 5th Jan so should 8th Jan commit be considered valid?
Any experts here?
"When" is an issue if we're considering the past commits valid. What we could instead do to simplify the problem somewhat is that revoking should put a warning on previous commits that they may be compromised.
They should be assigned to a random account