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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
