Re: GPG signing for git commit?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 4 Apr 2009, Chow Loong Jin wrote:
> 
> It crossed my mind that currently git commits cannot actually be
> verified to be authentic, due to the fact that I can just set my
> identity to be someone else, and then commit under their name.

You can't do that.

Well, you can, but it's always going to be inferior to just adding a tag. 

The thing is, what is it you want to protect? The tree, the authorship, 
the committer info, the commit log, what?

And it really does matter. Because the signature must be over some part of 
the commit, and since the SHA1 of the commit by definition contains 
everything, then the _safest_ thing is always to sign the SHA1 itself: 
thus a tag.

Anything else is always bound to only sign a _part_ of the commit. What 
part do you feel like protecting? Or put another way, what part do you 
feel like _not_ protecting?

So the way git does signatures protects everything. When you do a tag with 
"git tag -s" on a commit, you can absolutely _know_ that nobody will ever 
modify that commit in any way without the tag signature becoming invalid. 

And perhaps equally interestingly, that signature is now also easily 
separable from the history - which is interesting if you want to 
distribute your cryptographic parts separately (for example, you only use 
it _internally_ within a company or group, to mark some group-specific 
issues).

Also, related to that "separable" - the person signing on something is not 
necessarily the person marked as author, or even committing it anyway. One 
of the guiding goals for git was always that it should work well with 
"outside" flows, ie others passing patches around or using other SCM's to 
manage their own flow. 

Finally, on that same "separable" notion - imagine a big rewrite operation 
for whatever reason - like a big import into git, or a project re-writing 
their history because they ended up importing more history from old 
sources (or because they wanted to split a big project into subprojects). 
All of those invalidate any cryptographic signatures.

And all of those are events that you may still want to _update_ the 
signatures, but do you want to trust the one doing the conversion with the 
private keys? Obviously not. You could "wrap" the signing in a new 
"conversion signature", and have a signature to try to imply that the 
person doing the conversion "signs" the conversion. But the fact is, that 
doesn't mean the same thing.

With separate signatures (ie the "git tag -s" model), you can ask the 
people who signed the original repository to consider re-signing the 
rewritten one. See? Safe, flexible, and much superior.

The exact same thing goes for keys that get invalidated because they ended 
up being shown to be too weak or just flawed some other way, btw. That is 
a reason to re-sign, _without_ the repository necessarily changing.

You can do _none_ of these things sanely if you put the signatures into 
the commits themselves. 

So don't do it.

Btw, there's a final reason, and probably the really real one. Signing 
each commit is totally stupid. It just means that you automate it, and you 
make the signature worth less. 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. So signing each commit is simply missing the point. 

IOW, you don't _ever_ have a reason to sign anythign but the "tip". The 
only exception is the "go back and re-sign", but that's the one that 
requires external signatures anyway.

So be happy with 'git tag -s'. It really is the right way.

		Linus