What I gathered was that the author believes signing commits to be bad because;
1. It adds complexity that you otherwise don’t need
2. GitHub is the only place that cares or enables this and we don’t want to add to their Git monopoly
3. Signing the commit does little in reality since it doesn’t affect anything other than “Verified” on GitHub
4. Something about signatures being permanent?
Honestly I don’t get the argument. It’s not useless, not hard to set up, and not hard to maintain. You can initially lock yourself out of committing if you mess it up but usually it won’t lock you out. The extra assurance that someone signed the commit with a key that only they should have is really good if you care about that. That means someone can’t just spoof your name (which is very easy with Git) and sneak changes in more easily.
Humans are still a key part of working around source control. That means there is trust involved, and code is pretty sensitive. Folks now are also more distributed and it’s harder to control where they access work systems from, or if that environment is secure (eg coffee shop over VPN does little if you leave your computer unlocked and get up to get a refill). Any extra assurance can be meaningful, specially if it’s around your code.
If you want something to take more concrete action you can enforce that a bot reject any work with unsigned commits present. Your CI can do that quite trivially even.
It’s not perfect but it’s also, IMO, the future. GitHub supports it now but others will in time (or do). Then GitHub will have trained people to get it working and you don’t need to learn it again.
Long article for not really saying much.
Signing a commit creates an expectation that you approved of the code. And it's permanent, so easy to screw up with lasting effects.
But a signed commit really just means that whoever created it could run a CLI tool on your computer.
That means the expectation of quality created by signing is misleading.
In that case you probably need training or self-education. If your company tells you to sign commits but doesn’t tell you why, that’s on them. If you sign commits and don’t take the time to understand why, that’s on you.
Also, if you think quality comes from approval or signing a commit you’re also not understanding code quality because there is a huge amount of terrible approved code out there.
Just because someone doesn’t understand something doesn’t mean it’s bad or shouldn’t happen. It means that there’s possibly a gap that’s causing the misunderstanding that should be addressed, or the wording changed to be less ambiguous.
"just" is doing a lot of work there. Someone running their code on your computer is a big deal! Hopefully it's benign and sandboxed, in the case of webpages and JavaScript, but if an attacker is running code, be it a cli tool or otherwise, on your computer, you should be really worried. If somebody is signing git commits under your name on your computer, they could just as easily wait until you login to your bank's website and steal your money.
I'll also post the private key, because one of my dreams is to as fully enumerate the space of public/private keypairs as possible!
Now everyone is happy right?
Lets be real. It's more about people wanting a blame ratchet. It doesn't increase trust. And I 100% accept the reasoning that Github is something to be avoided. I will not continue submitting tokens to Microsoft's datasets.
Generally, I think signed commits are a good thing and mitigate GitHub's centrality, as currently, the only proof that Bob Fooman did a specific commit is that GitHub permitted it to occur with the given email address.
Essentially, this means that the root-of-trust (with unsigned commits) _just is_ whoever the hoster is, creating enormous centifugal force towards trusted repo hosters.
With signed commits, I can verify that the same Bob who signed a commit in 2008 is the guy who's signing commits now (if it's the same key; it might not be, but we have keyservers to track key expiries and retirings as well.) So you can take that repo and put it on codeberg or whatever and it's still verifiably Bob, and you don't have to wonder about the security of the previous repo hoster.
I also think that the meaning of a signed commit is pretty clear: "I approve (and did) these changes to the codebase." I have no idea what the legal situation is, but I'd be surprised if the intent was not recognized. (but IANAL either; any actual lawyers here wanna comment?)
Finally, I thought this guy's weird rant about key management back in the Before Times was telling. As a fellow Old, I'm pretty good at picking up oldsmell (it takes one to know one,) and this sounded a lot like someone crying out under the weight of several decades of complexity increase.
I get it. I want to scream sometimes too. But you know what? key signing is not weird, new, complex tech anymore. Tweens (especially ASD-spectrum tweens) can even lecture you on this topic :) This guy talks like it's this huge weird new thing and who took away all those nice plaintext endpoints anyway, let me tell you, back in the day, all you needed was telnet and --
Finally, the part I can speak to is the potential benefit. Aside from the obvious one I outlined above -- decentering the github repo host as root-of-trust -- there is also probably a lot of benefit that I can't see, and that, perhaps, no one yet sees, but will become plain after some future supply-chain attack.
There are known knowns, known unknowns, and unknown unknowns, and the last bucket is the most important for any serious professional in this industry. Security, like dressing for weather, is about layers because you never know when you'll need that overcoat.
- signed, former CSO of a very small startup, and current IC at another, larger startup
Often the value is only apparent when stuff goes wrong - “wow we’re lucky we made folks use 2FA because it saved our business” - but if you do it right you hopefully don’t end up with stuff going wrong and then also not reveal the actual value of prevention.
So you end up in a weird sort of limbo of “that will never happen to my company!” Until it does. Then it’s top priority and “why were we not doing this all along?! Our people are idiots!” Except the people saying that were also the people that dropped the security budget and cancelled the security projects and initiatives.
This is completely untrue. GitLab does this. GitTea does this. You can do this manually in the command line.
I don’t think the author knows that they’re talking about.
Also, I just found this. This current, ongoing attack against GitHub is nicely mitigated by signed commits. If everyone signed commits, before cloning a repo, you could check to see if (a) the author of the fork added anything of value and (b) if the author of the fork has added anything else of value to GitHub, and (c) who signed the majority of the commits to the project.
https://arstechnica.com/security/2024/02/github-besieged-by-...