For anyone wondering - why would I need it? I’m already signed in to github, the commit is commited using my ssh-key, Github knows it’s me. Why would I need another verification?

Here’s why. https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g . If someone commits with your email (or github noreply email, which is public), it will get attributed to you. I was just trying it with colleauges account, and so far I haven’t found any way how to tell that it really wasn’t him.

I think the author balloons gpg signing into a problem and overlooks the impersonation aspect the signatures try to mitigate. Out of the cons listed:

Unknown, possibly unlimited future liability for the consequences of running code in a commit you signed

I don’t see how proof of commit authorship would change the warranties a piece of software is supposed to deliver. Sure it’ll make the untruthful claim of non-authorship harder (i.e. “I didn’t write this” when they in fact did); on the flipside, the signature would also protect the author from an impersonation attempt of a malicious/deceiving piece of code. Either way, I wouldn’t worry much about it.

Further implicitly cementing GitHub as a centralized trust authority in the open source world

This doesn’t hold. Commit signature is a feature of git itself, even though the article chooses to focus on GitHub. And afaik github integration of signatures doesn’t break code hosting elsewhere, GH merely allows you to register your GPG signature with them so they’re able to validate the commits, but the author is still able to enroll the same GPG key to other hosts.

Introducing unknown reliability problems into infrastructure that relies on commit signatures

Not sure what they mean by this. If your infra is set up to require signature, they might have valid concerns about impersonation and/or operate in a regulated environment.

Temporary breach of your GitHub credentials now lead to potentially permanent consequences if someone can smuggle a new trusted key in there.

This is a temporary problem, not permanent. After the breach the genuine author can go to the settings and delete the compromised key. Commits signed with a deleted key fallback to an unverified status.

New kinds of ongoing process overhead as commit-signing keys become new permanent load-bearing infrastructure, like “what do I do with expired keys”, “how often should I rotate these”, and so on.

Same with SSH keys, security is often a trade-off with convenience.

I’ve never understood the point of signing commits. If i can push a commit to a repo, then i can also add my own keys to the repo as well right? So malicious actor with my password can happily push signed commits?

Do many people actually sign commits?

Great read.

I agree about the culture problem. People want to slap extra encryption into things, like a spoiler on a hatchback.

The core issue is that the problem being addressed by signed commits is already solved.

Did MajorHavoc write this commit?

If it has my username, on GitHub, you’re confident it’s my commit.

Alternately, it could be someone with so much access to my SSH keys, or to GitHib’s infrastructure, that they could easily sign commits as me, anyway.

Signed commits might become more compelling when we start to favor fully open source federated git solutions. At that point, if I’m famously trustworthy, and the repo I submitted a signed commit to is not, then my signature could mean something.

But even then, there’s the risk that someone interprets my 4 minute typo fix as my having some clue whether the repo is actually safe to use…

Agreed, and I have more arguments against commit signing.

• Commit immutability is undesirable, and mutable commits are not compatible with signing. For instance, pull requests are squashed and rebased to keep linear history, and changes are cherry picked around. It does not change authorship, however it changes hashes and invalidates any signatures. Or, say, one wants to adopt an otherwise FOSS project which though contains some copyrighted material in its repository, which needs to be filter-branched away, again invalidating the signatures.
• In our world where stuff randomly gets criminalized I prefer to avoid being undeniably linked to my code.

BTW this topic has common considerations with now mandatory (on GH and more places) 2FA. For the latter reason, and also for own convenience and for reducing risk of losing access to your account (which I assess as much higher than risk of leaking my password to third parties) I make second factor public, effectively reverting to 1FA.

I think he should reconsider his stance on signing commits.

Just to be clear, this is about 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 even 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. 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 (ie GitHub) cannot be trusted over indefinite timescales, and problems will arise eventually.

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.