32
Unsigned Commits
(blog.glyph.im)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
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.
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.
I almost wanted to call the linked post as clickbait, based on its terse title and the bold claim made in the subheader ("I’m not going to cryptographically sign my git commits, and you shouldn’t either"). But there was just enough substance to present and justify a colorable argument in the post. It just wasn't the same argument presented in the title, and took me way too long to determine what the grievance was directed at.
Worthwhile read? Eh, not until its position is clarified to not be confusing.