32
Unsigned Commits (blog.glyph.im)

I'm curious to hear what the Lemmy programming community thinks of this!


  • The author argues against signing Git commits, stating that it adds unnecessary complexity to systems.
  • The author believes that signing commits perpetuates an engineering culture of blindly adopting complex tools.
  • The consequences of signing Git commits are likely to be subtle and not as dramatic as some may believe.

Archive link: https://archive.ph/vjDeK

you are viewing a single comment's thread
view the rest of the comments
[-] litchralee@sh.itjust.works 20 points 9 months ago* (last edited 9 months ago)

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.

[-] litchralee@sh.itjust.works 5 points 9 months ago

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.

this post was submitted on 25 Jan 2024
32 points (88.1% liked)

Programming

17314 readers
95 users here now

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

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS