Hacker News Reader

Comment by ilammy | Hacker News Reader

I tend to agree with the argument Linus put forward a long time ago, saying that there is little reason to sign commits instead of tags in git.

* Commit references the tree. If you sign the entire commit object – which is what you want, not leaving a way to change something about the commit without invalidating the signature – you sign the file tree as you saw it and implicitly all its history. Might as well sign the tag then.

* Signatures separable from the commit have a benefit of allowing someone other than the author and committer at the time to certify authenticity of the file tree. For example, if the key needs to be rotated later, you can slap a new signature over the previous one.

* Signing every single commit is tedious, so you're bound to get it automated at some point. Now your signatures are worth less because your keys are always around to indiscriminately, automatically sign whatever.

View on HN

I kind of agree with this argument, too.

The process of signing a commit is used in a kind of wrong manner, I suppose, because of your mentioned points.

The "view of the file tree as you saw it" basically implies that signed commits aren't worth anything if the code is refactored or changed later, which inevitably it will.

Using tags as a reference point, however, is the idea of snapshotting a mutually agreed state between multiple parties working on the project.

I think you could take this a little further, and use it to implement a Q&A workflow, where e.g. a code review team and a testing team should sign a specific snapshot as "working as we saw it", and that could integrate very well if you e.g. have a semantic version epoche of your project.

Tags are commonly used for library development, but are effectively never used for application development. Signing commits for application development makes a lot of sense, since no one uses tags.

> It's bound to get automated at some point

Definitely — it already is automated. Git can sign commits using your SSH key automatically, and assuming you have something like ssh-agent running, you aren't going to need to enter your password or tap your Yubikey or whatever every time. That doesn't mean it's worthless for application development. While the developer machine being compromised is still a risk, it still mitigates man-in-the-middle attacks where your repository is compromised, or a pipeline betweeen your repo and the build machines are compromised, and an attacker can spoof commits. With signed commits, the attack wouldn't work: you don't need a chain of trust in between build servers and dev machines, you just need to trust the dev machines and the build servers. Everything in between is unable to modify the tree without getting caught.

Signing tags doesn't provide extra security, either; if the dev machine is compromised, ultimately the dev who is signing the commits can't trust their own machine to tell them what's on disk and what they're signing. And if the build server is compromised, you can't trust it to ignore unsigned commits, or commits where the signatures don't match.

The last point can be mitigated by a hardware based security key(nitrokey,yubikey,etc).

Key would then by not on your device so extraction would be difficult or impossible.

You would need to touch the key to grant the sign request which would prevent any signing without you noticing.

It's more about the slippery slope of security vs convenience.

I do git rebase -i often. Do I want to touch my yubikey exactly 37 times for the 37 commits amended, or do I want to touch it once and just trust the software for the next N seconds to sign only these commits and not anything else?

Now, if I'm the verifier, do I trust the signer to do it properly? Or the half their commits are actually made by their cat and automatically signed?

Signing a tag is a relatively rare and very deliberate action. A more secure approach is less likely to impact convenience, reducing the chance of compromising security because it was inconvenient.

I think that's precisely the point. You wouldn't want to touch your security key every time you commit anything. Given the (intentional) high friction, it's probably best left for operations that are high value, such as tags or releases

I think ssh keys signing goes a long way to point 3. I haven't looks if you can (or if it matters) to sign with an ssh certificate, but that would be useful to add some context to the signature too.

The point he was making was not about the tech or tools to sign commits.

It was about the laziness of humans not actually reading the code thoroughly when they sign it, and therefore negating the point of ledging/signing the state of the project.

Reply on news.ycombinator.com