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.

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…

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.