A Git Horror Story: Repository Integrity with Signed Commits (2012)

mikegerwitz.com

89 points·pmoriarty··9 comments

Interesting, but the commit that introduced the malicious changes wouldn't be signed by the alleged author's key.

Also I'd trust anyone who denies adding a backdoor like this. Why would anyone do this with their name attached to the change?

What you'd actually do is change the author to "Anonymous Coward <nobody@android.com>" ;)

https://android.googlesource.com/platform/packages/apps/Glob...

Hah. That is an interesting commit! Definitely a smart move if you're pushing an unpopular change to an open source project.

In the given scenario, the author signs tags and not commits. So the malicious commit wouldn't be signed at all because no commits are signed, and therefore nothing would look out of place.

The article is arguing that only signing tags is insufficient, and that you should sign every commit individually to prevent this scenario.

Sounds like this is solving a non-problem, legitimized by a contrived hypothetical.

That seems to be the consensus every time this is posted.

(2012)

If the changes were already in git, werent they signed before he merged?

Gitlab supports push rules that prevent you from pushing on-signed stuff to the repo (which I’m using, and while gitlab is good at this; it’s very easy to accidentally not sign a bunch of commits and have to amend a bunch- which I’m mostly too stupid to do)

I mean. Isn’t the whole point that you only sign your own stuff? Inevitable on merge, sure. But on merge the stuff is all ready at the origin. No?

Pretty sure Github also has an option for enabling signed only commits.