Programming

Just to be clear, this is about how signed commits appear in GitHub, right? Native Git signing is as robust -- and complex -- as it's always been, with the user having to keep their own GPG private and public keys. Managing these keys is the same process for signing outbound emails or preparing to receive inbound encrypted emails, with the attendant usability quirks like dealing with key revocation.

The author's main gripe appears to be with how GitHub presents a veneer of trust based on the commit signature, but not in pursuit of a cognizance security objective. That the veneer of "verified" could be confused with "safe to compile/execute" could regress overall security of users. I think this position is well-supported by the examples given.

But what I don't see is how this relates to Git signing at-large, when GitHub is not involved. The title of this Lemmy post and the blog post is "Unsigned Commits" and the author only ever mentions the consequences as they pertain to GitHub. Yet the same concern as the author's post can apply here: users who don't recognize that this is a GitHub-specific grievance might think ALL Git commit signing is useless, which is wrong. And that mistake would regress overall security of all Git users.

An example of Git signing outside of GitHub is the Linux kernel. Note that "PGP keys" are what GPG uses to sign the commits; that's not confusing at all.

PGP helps ensure the integrity of the code that is produced by the Linux kernel development community and, to a lesser degree, establish trusted communication channels between developers via PGP-signed email exchange.

Ever since the 2011 compromise of core kernel.org systems, the main operating principle of the Kernel Archives project has been to assume that any part of the infrastructure can be compromised at any time. For this reason, the administrators have taken deliberate steps to emphasize that trust must always be placed with developers and never with the code hosting infrastructure, regardless of how good the security practices for the latter may be.

As the Linux folks so eloquently put it, and in firm agreement with the author of this post, the infrastructure (kernel.org or GitHub) cannot be trusted over indefinite timescales, and problems will arise eventually. In disagreement with the author but in agreement with the Linux people, signed commits decentralize the trust, making the infra less useful to attack.

I personally still encourage Git signing, just like I would encourage email signing and encryption. But not just because GitHub is telling me I should. Every email and commit I produce, I should sign; the author here says I shouldn't, and I disagree. Signatures are valid for a specific purpose, until the day the signature key is revoked, which I can always do, however annoying.

TL;DR: Git signing is fine. What GitHub built atop native Git signing is questionable. Do sign stuff, but for real reasons, not just because GitHub tells you to.