From: Linus Torvalds Date: Sun, 03 Jul 2005 00:17:43 GMT Subject: Re: Tags Message-ID: In-Reply-To: <42C727FC.3030900@gmail.com> On Sat, 2 Jul 2005, A Large Angry SCM wrote: > > Linus Torvalds wrote: > > > > None of git itself normally has any "trust". The SHA1 means that the > > _integrity_ of the archive is ensured, but for some things (notably > > releases), you want to have something else. That's the "tag object". > > > > But can't the commit object do this just as well by signing the commit text? Yes and no. Technically yes, absolutely, you could add a signature to the commit text. However, that's just wrong for several reasons: First off, the signing is not necessarily done by the person committing something. Think of any paperwork: the person that signs the paperwork is not necessarily the same person that _wrote_ the paperwork. A signature is a "witness". For an example of this, look at the signatures that we've had for a long time on kernel.org: check out the files like "patch-2.6.8.1.sign". That's a signature, but it's not a signature by _me_. It's kernel.org signing the thing so that downstream people can verify things. And it would be not only wrong, but literally _impossible_ for me to do it in the commit. I don't have (or want to have) the kernel.org private key. That's not what the signature is about. kernel.org is signing that "this is what I got, and what I passed on". It's not signing that "this is what I wrote". In a lot of systems, you tag something good after it has passed a regression test. Ie the _tag_ may happen days or even weeks after the commit has been done. So any system that signs commits directly is doing something _wrong_. Secondly, you can say that you trust other things. In git, you can tag individual blobs, and you can tag individual trees. For an example of where it makes sense to tag (sign) individual file versions, we've actually had things like ISDN drivers (or firmware) that passed some telco verification suite, and in certain countries it used to be that you weren't legally supposed to use hadrware that hadn't passed that suite. In cases like that, you could sign the particular version of the driver, and say "this one is good". (Yeah, those laws are happily going away, but I think the ISDN people in germany actually ended up doing exactly that, except they obviously didn't use git signatures. I think they had a list of file+md5sum). Finally, it's a tools issue. It's wrong to mix up the notion of committing and signing in the same thing, because that just complicates a tool that has to be able to do both. Now you can have a nice graphical commit tool, and it doesn't need to know about public keys etc to be useful - you can use another tool to do the signing. Small is beautiful, but "independent" is even more so. > Your tendency is to use tag objects as a permanent, public label of some > state. Signing the commit text or the email stating that commit > ${COMMIT_SHA} would work just as well for verification purposes. Well, according to that logic, you'd never need signatures at all - you can always keep them totally outside the system. But if they are totally outside the system, then you have to have some other mechanism to track them, and you can never trust a git archive on its own. My goal with the tag objects was that you can just get my git archive, and the archive is _inherently_ trustworthy, because if you care, you can verify it without any external input at all (except you need to know my public key, of course, but that's not a tools issue any more, that's about how signatures work). So by having tag objects, I can just have refs to them, and anything that can fetch a ref (which implies _any_ kind of "pull" functionality) can get it. No special cases. No crap. Do one thing, and do it well. Git does objects with relationships. That's really what git is all about, and the "tag object" fits very well into that mentality. Linus