4 ms·

"Signing each commit is totally stupid." Linus Torvalds http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.c

"Signing each commit is totally stupid." Linus Torvalds 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...

epistasis 11y ago
That's a pretty unconvincing rant.
- shopkins 11y ago
  How so?
  - epistasis 11y ago
    Once you strip away the insults, what's left appears to be: 1) It's unclear what we should sign on a commit, therefore we shouldn't. I'm not sure what to make of that. 2) Since a key may be revoked, any signatures should not go into the commit. Presumably Torvalds thinks that tags should be deletable, but commits should not, or something. 3) That if all commits are signed, then it become automated, and therefore somehow not worthwhile. Meanwhile, automated signing seems awesome because we know that at least the signer had possession of the key. I can't really extract much more logic out of that post, and none of it sways me in the slightest.
    - pdkl95 11y ago
      While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified. This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata". The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location. The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future. > insults I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult. > therefore we shouldn't Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s". [1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years. [2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key
    - vacri 11y ago
      Ah, the curse of being Torvalds. He writes 600 words clearly explaining his position in an educational manner, and near the end, says an action is 'stupid' (not a person!) in one single sentence. This is characterised as "once you strip away the insults". You've just insulted Torvalds more than he insulted the person he was responding to; hardly a position to be moralising from. Fuck that shit.
deleted 11y ago
[deleted]
berdario 11y ago
That assumes that you verify the contents of EVERY commit since the last tag, when you sign a new tag. NO ONE i know does this. Conversely, everyone expects to be held, and hold others, accountable for the contents of their commits. We don't have second preimage attacks on sha1 yet, but thinking of keeping signatures separates only buys you flexibility (which is not used by most projects currently on github) and maybe a bit of performance, for a process that is much more brittle. Also, with things like this: > It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project. Let's not do some "appeal to authority" BS with a myopic post from 7 years ago.
- cyphar 11y ago
  > > It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. > He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project. Git does that automatically for you. Git self-verifies the DAG (which is why it takes a while to warm up on the kernel repo because of the insane number of commits). So he's not missing the point.
  - ashitlerferad 11y ago
    I thought the GP comment was talking about reviewing the code changes rather than verifying the hash chain.
    - berdario 11y ago
      Precisely

"Signing each commit is totally stupid." Linus Torvalds 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...

epistasis 11y ago

That's a pretty unconvincing rant.

shopkins 11y ago
How so?
- epistasis 11y ago
  Once you strip away the insults, what's left appears to be: 1) It's unclear what we should sign on a commit, therefore we shouldn't. I'm not sure what to make of that. 2) Since a key may be revoked, any signatures should not go into the commit. Presumably Torvalds thinks that tags should be deletable, but commits should not, or something. 3) That if all commits are signed, then it become automated, and therefore somehow not worthwhile. Meanwhile, automated signing seems awesome because we know that at least the signer had possession of the key. I can't really extract much more logic out of that post, and none of it sways me in the slightest.
  - pdkl95 11y ago
    While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified. This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata". The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location. The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future. > insults I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult. > therefore we shouldn't Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s". [1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years. [2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key
  - vacri 11y ago
    Ah, the curse of being Torvalds. He writes 600 words clearly explaining his position in an educational manner, and near the end, says an action is 'stupid' (not a person!) in one single sentence. This is characterised as "once you strip away the insults". You've just insulted Torvalds more than he insulted the person he was responding to; hardly a position to be moralising from. Fuck that shit.

deleted 11y ago

[deleted]

berdario 11y ago

That assumes that you verify the contents of EVERY commit since the last tag, when you sign a new tag. NO ONE i know does this. Conversely, everyone expects to be held, and hold others, accountable for the contents of their commits. We don't have second preimage attacks on sha1 yet, but thinking of keeping signatures separates only buys you flexibility (which is not used by most projects currently on github) and maybe a bit of performance, for a process that is much more brittle. Also, with things like this: > It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project. Let's not do some "appeal to authority" BS with a myopic post from 7 years ago.

cyphar 11y ago
> > It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one. > He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project. Git does that automatically for you. Git self-verifies the DAG (which is why it takes a while to warm up on the kernel repo because of the insane number of commits). So he's not missing the point.
- ashitlerferad 11y ago
  I thought the GP comment was talking about reviewing the code changes rather than verifying the hash chain.
  - berdario 11y ago
    Precisely