I don’t think you should sign your Git commits

&gt; With signed commits, you are saying something permanently, but you don’t really know what it is that you’re saying.<p>I know perfectly well what I&#x27;m saying. I&#x27;m saying that this particular commit has been authored by me (or someone who possesses my key), not by anyone else who typed &quot;--author=seba_dos1&quot; into their command prompt.<p>I&#x27;m not saying anything else about the commit. I&#x27;m not saying &quot;this code is safe&quot;, I&#x27;m not saying &quot;I audited this source tree&quot;, I&#x27;m not even saying &quot;I authored the code&quot; just with the signature alone - I&#x27;m saying &quot;I authored the commit, and here&#x27;s the proof&quot;. Whatever you do with that information is up to you - and usually, for most people, this information is mostly useless, but there are cases where it&#x27;s not.<p>I&#x27;m really baffled by people who seem to try very hard to attach some extra meaning to this. &quot;What is the possible security benefit?&quot; - there&#x27;s none, obviously (at least not on its own). It&#x27;s not about security at all, what made you think it was about security in the first place?<p>A GPG signature attached to an e-mail I wrote does not tell you that I&#x27;m not lying, but it can be useful nevertheless.<p>&gt; It’s worth noting that only GitHub will do this, since they are the root of trust for this signing scheme<p>`git show --show-signature &lt;rev&gt;`. There&#x27;s no need for GitHub for this.

The analogies used do not work but are strongly being used as a foundation for the rest of their arguments, so the entire reasoning feels weak and misguided.<p>No, we don&#x27;t sign things with keys in real life, the same words being used in two different spheres of life do not make one &#x27;false&#x27;.<p>The HTTPS one is more of a rabbit hole of misunderstanding — trying to draw similarities with https and git signing is probably the root of the problem here. I&#x27;d suggest considering it on its own merit, and trying to understand why git commit signing was introduced, and what you would use it for given the cases.<p>Also worth noting that some of the info is wrong, Github is not the root of trust, and also aren&#x27;t the only one who encourage it; Gitlab have a similar guide and badge FWIW.

The analogy to notarizing everything you sign is misguided. Notarization is not required to prove you signed something -- it&#x27;s usually required to make a legal claim about something in the document, e.g. &quot;I am making these claims under penalty of perjury, and this independent party watched me make those claims.&quot;<p>Commit signing provides an integrity and attribution, but that&#x27;s it. The author seems to think there&#x27;s some broader meaning to it, but there isn&#x27;t. Broader meaning can be built on top of commit signing, but that&#x27;s a separate system that can have a lot of different forms.<p>I remember reading similar stuff about code signing in the early aughts. The complaints weren&#x27;t about code signing, they were about accountability. &quot;If I sign this then that means someone can hold me responsible for something that goes wrong.&quot; But they can do that anyway -- code signing didn&#x27;t create a whole new form of tort that was completely impossible before.<p>There&#x27;s this sect of software people that seem to think that it&#x27;s impossible to make legal attributions without the involvement of asymmetric cryptography. Like, they could just show up to court and go &quot;You can&#x27;t prove that I wrote that software because it&#x27;s unsigned&quot; and so any legal action against them is impossible. And therefore being forced to sign stuff opens them up to a whole new universe of legal action.<p>In reality, if someone wants to sue you, they will. If they say that you wrote something, and it looks and smells a lot to a court like something you wrote, the court will determine that you wrote it. So sign your commits -- not because it&#x27;ll magically make bugs go away, but because supply chain integrity is turning into a real problem really quickly, and this kind of stuff is just table stakes at this point.

This falsely assumes signing and trust is somehow tied to GitHub. GPGs web of trust has issues but it allows verifying outside GitHub.

<a href="https:&#x2F;&#x2F;github.com&#x2F;jayphelps&#x2F;git-blame-someone-else">https:&#x2F;&#x2F;github.com&#x2F;jayphelps&#x2F;git-blame-someone-else</a> is a pretty good reason to sign your commits

Completely correct that you should have a reason for signing something which goes beyond the vacuous “why not”.<p>In my own work, the surrounding context is sufficient verification.<p>By the way: patch attestation [1] is perhaps somewhat related. Pretty well-thought out techniques for verifying that patches sent via email.<p>[1] <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;813646&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;813646&#x2F;</a>

This is weak. Making commits more meaningful does not mean we need to handle the history of previous unsigned commits as the article asserts.<p>You would simply enact a policy that says from this day, all future commits must be signed in order to prevent future identity theft.<p>Yes, bad people may have snuck bad code into your repo in the past. it does not follow that it is unworthy to prevent bad code entering the repo in future

A lot of statements but with an important convoluted point: git signing happens with a public key that nobody knows how to verify properly. So should we sign them today, without being able to verify yet?<p>Well, that isn’t 100% true. GitHub knows. But relying on GitHub is a good reason to not use the feature <i>at all</i>, imo. A bit stallmanesque perhaps? Maybe.<p>I have absolutely no idea about your ssh keys, which goes back to decentralized self-sovereign identity being an unsolved problem (socially and administratively, not technically). Add commit signing to the giant list of use cases, I guess.

Changes are not an issue. If a maintainer says all future commits will be signed then that is fully verifiable. The fact that older commits arn&#x27;t in no way effects the trust

I can understand signing patches sent over email. But for commits in any decent organisation one has to log in the network, have access rights to git, go through code review, and then, finally, you have code committed into the repo. In these cases signing commits does not add much, if anything.

We have a policy for our QA to sign release candidate tags. It&#x27;s purely for non repudiation reasons. That&#x27;s the sole purpose to keep verification on validity of the commit chain.

I, too, used to be scared of my &quot;middle school permanent record&quot; except just last week, I witnessed at $work a decision being reached to let old history stay in TFS and only import the current (head if you will) in git with no history at all.<p>I am not saying don&#x27;t worry about the future or that the future doesn&#x27;t matter. For most situations, git history won&#x27;t matter. There is no such thing as a permanent record, not one that most people will care about anyway.<p>Here is my reason for why we don&#x27;t need commit signing — the commit must stand on its own. Either you understand the change and approve of it, regardless of whether it was signed by Linus Torvalds or Kim Il Sun, or you don&#x27;t. If you don&#x27;t understand the change (or the code base) and the code base is important enough for you to go looking for a signature, chances are you should be paranoid if someone got into Linus&#x27;s computer and stole his private keys.<p>Tl;Dr don&#x27;t think too much about git signing. Do what makes you happy but know it doesn&#x27;t matter either way.