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?
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…
However, it’s a pretty old article - maybe it’s already fixed? I’ll have to try that.
EDIT: It still works, and you can just use the github noreply address, which is ID+username@users.noreply.github.com . The commit gets linked to their profile, and is shown on their profile page, has their username and profile picture. I haven’t figured out any difference between legit and impersonated commit so far, but maybe it’s hidden somwhere in the repo administration.
So, there you have it. That’s what PGP signing is for.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
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
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…
Apparently, that’s not true: https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g
However, it’s a pretty old article - maybe it’s already fixed? I’ll have to try that.
EDIT: It still works, and you can just use the github noreply address, which is ID+username@users.noreply.github.com . The commit gets linked to their profile, and is shown on their profile page, has their username and profile picture. I haven’t figured out any difference between legit and impersonated commit so far, but maybe it’s hidden somwhere in the repo administration.
So, there you have it. That’s what PGP signing is for.
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:
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.
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.
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.
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.
Same with SSH keys, security is often a trade-off with convenience.