While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as pa

While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified. This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata". The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location. The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future. > insults I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult. > therefore we shouldn't Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s". [1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years. [2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key