Unsigned Commits

Anyone can set any name and email on any commit.

Signing is a basic way to have some defence against people forging your name and email for commits.

That's it.

Whatever "signing" means in other contexts is just semantic wordgames. Witches have come out of the inquisition less tortured than all these analogies about "signing" in different contexts. Everyone understands that "signing" in "signing a commit" means something different than in "signing a contract".

I am not really convinced.

First, HTTPS is here to authenticate the server to all users, because it is important that no user wrongly believes that it connected to the website it wanted. Many times it does not matter (e.g. a random blog), but when it does matter, it does matter for all users. Git signing is different: if I sign my commit, I really don't care if whoever runs it checked my signature; I sign it so that someone who cares (and knows what it means) can check it.

Second, I don't see the lock-in with GitHub. Signing a commit is not about getting a "verified" badge, and the public key is not limited to GitHub. On the contrary, because the signature goes with the patch, I would say it really does not depend on GitHub at all. GitHub showing information about it does not make GitHub own it.

Third, I don't get the comparison with the paper signature either: my signature on a document has some kind of legal meaning, so I won't just put it everywhere "just in case". My PGP signature doesn't: I am pretty sure I can even PGP-sign a contract document (e.g. the *.pdf) and it won't be equivalent to me writing my signature next to my name. Of course it can prove that I did PGP-sign that document, so in the case of a highly illegal document that I should not link myself to, probably I should not PGP-sign it.

It’s worth noting that only GitHub will do this, since they are the root of trust for this signing scheme.

This is wrong : the commit signature is stored inside git:

  commit 96afe9a2af7d72fbd6cd790143388c47d9f91d3e (HEAD)
  gpg: Signature made Thu 28 Sep 2023 10:12:38 AM CEST
  gpg:                using RSA key 653A3D280EB42CB78CF327CFEDDED470D80A522C
  gpg: Good signature from "Jack <jack@domain.com>" [ultimate]
  Author: Jack <jack@domain.com>
  Date:   Wed Sep 27 10:00:24 2023 +0200
    commit message

The author seems to miss a lot of git internals : the name and email in the commit message are nothing but text, everybody can write anything. The one who wrote a commit may not be the one who push the commit in github (or in any kind of remote). But reading the "pro/con" at the end of the article should be enough to throw the whole things away :/

My GPG signatures are stored in the git commits themselves, and have nothing to do with GitHub. Anyone can validate them with git-verify-commit(1). They are there to communicate "if you trust my GPG key, you can be certain I made these commits". There is no argument to be made that the signature makes any claim about past or future commits, either.

What a confusing article.

Is there a reason there isn't a default signing key generated for each cloned/created repo, or an easy option to toggle to do the same?

Knowing a commit came from one specific clone of a repo would be useful, even if it ended up with more than one key per user. (you could even sign a set of keys to attest that they are you)

Gitlab also shows a badge for signed commits.