Hacker News new | ask | show | jobs
by 1attice 841 days ago
Agreed about the writing quality (lack of focus). I thought the bit about liability was a stretch; I don't think this guy is a lawyer, so I'm not sure why he thinks he's in a good position to assess.

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

1 comments

Thanks, well said. A lot of security things are quite abstract and difficult to measure the value of.

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.

Agreed.

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-...