Re: Git-commits mailing list feed.

["David A. Wheeler" <dwheeler@dwheeler.com>]

On Sat, 23 Apr 2005, Linus Torvalds wrote:
> > That means that we don't "strip them off", because dammit, they DO NOT
> > EXIST as far as git is concerned. This is why a tag-file will _always_
> > start with
> >
> >     commit <commit-sha1>
> >     tag <tag-name>
> >
> > because that way we can use fsck and validate reachability and have 
> > things that want trees (or commits) take tag-files instead, and git 
> > will automatically look up the associated tree/commit. And it will do 
> > so _without_ having to understand about signing, since signing is for 
> > trust between _people_ not for git.
>
>> And that is why I from the very beginning tried to make ti very clear
>> that the signature goes at the end. Not at the beginning, not in the
>> middle, and not in a different file. IT GOES AT THE END.

It may be better to have them as simple detached signatures, which are
completely separate files (see gpg --detached).
Yeah, gpg currently implements detached signatures
by repeating what gets signed, which is unfortunate,
but the _idea_ is the right one.


Paul Jakma wrote:
> Ideally, there'd be an index of signature objects by the SHA-1 sum of 
> the object they sign, as the signed object should not refer to the 
> signature (or the second of the above is not possible).

Yes, and see my earlier posting.  It'd be easy to store signatures in
the current objects directory, of course.  The trick is to be able
to go from signed-object to the signature; this could be done
just by creating a subdirectory using a variant of
the name of the signed-object's file, and in that directory store the
hash values of the signatures.  E.G.:
 00/
    3b128932189018329839019          <- object to sign
    3b128932189018329839019.d/
    0143709289032890234323451
 01/
    43709289032890234323451          <- signature

> The latter of the two points would, in combination with the former, 
> allow for cryptographic 'signed-off-by' chains. If a 'commit' is signed 
> by $RANDOM_CONTRIBUTOR and $SUBSYSTEM_MAINTAINER and $ANDREW, you know 
> its time to pull it. Would also work for things like "fixes only" trees, 
> where (say) a change must be approved by X/2+1 of a group of X hacker 
> providing oversight -> looking up the commit object's signatures would 
> tell you whether it was approved.

Right.  Lots of tricks you can do once the signatures are there,
such as checking to counter repository subversion
(did everything get signed), finding out who introduced a malicious
line of code (& "proving" what key signed it first), etc.
There are LOTS of reasons for storing signatures so that they can
be checked later on, just like there are lots of reasons for storing
old code... they give you evidence that the reputed history is true
(and if you doubt it, they give you a way to limit the doubt).

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/