4 ms·

I'm happy about this but I thought signing commits wasn't a good thing to do. Linus wrote a lengthy post[1] on this saying you should only care to sign tags.

I'm happy about this but I thought signing commits wasn't a good thing to do. Linus wrote a lengthy post[1] on this saying you should only care to sign tags. (I'm not a security person) Read svckr's comment below and link #1 - what I was saying here before my edit was wrong. :D 1: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... (2nd post)

fabulist 11y ago
I would add that you shouldn't trust GitHub not to lie to you, and verify signatures for yourself. One need not attribute malicious motives to GitHub in this scenario; they could get hacked, served with an NSL, successfully man-in-the-middled, or inadvertently hire a bad actor.
- coroutines 11y ago
  I completely agree. I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.
svckr 11y ago
I'm not 100% sure what you're saying here, but in the post you linked, Linus seems to be referring to a hypothetical solution where you're not signing the SHA of a commit but some subset. When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses. The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit. With a tag, you'll just update the tags and the rest of the branch remains unchanged. I hope, together with the thread you posted, this at least makes some sense. Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.
- coroutines 11y ago
  Yeah, I think my understanding is flawed - but trust in the Linus :D He has some affiliation with git or something.. (thank you, kind expert)

fabulist 11y ago

I would add that you shouldn't trust GitHub not to lie to you, and verify signatures for yourself. One need not attribute malicious motives to GitHub in this scenario; they could get hacked, served with an NSL, successfully man-in-the-middled, or inadvertently hire a bad actor.

coroutines 11y ago
I completely agree. I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.

svckr 11y ago

I'm not 100% sure what you're saying here, but in the post you linked, Linus seems to be referring to a hypothetical solution where you're not signing the SHA of a commit but some subset. When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses. The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit. With a tag, you'll just update the tags and the rest of the branch remains unchanged. I hope, together with the thread you posted, this at least makes some sense. Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.

coroutines 11y ago
Yeah, I think my understanding is flawed - but trust in the Linus :D He has some affiliation with git or something.. (thank you, kind expert)