Re: Git-commits mailing list feed.

[Paul Jakma <paul@clubi.ie>]

On Sun, 24 Apr 2005, David A. Wheeler wrote:

> 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.

Hmm, what do you mean by "repeating what gets signed"?

> 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;

Two ways:

1. An index of sigs to signed-object.

(or more generally: objects to referring-objects)

2. Just give people the URI of the signature, let them (or their
    tools) follow the 'parent' link to the object of interest

> 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

You could hack it in to the namespace somehow I guess. I'm not sure 
hacking it in would be a good thing though.

I think it might be more useful just to provide a general index to 
lookup 'referring' objects (if git does not already - I dont think it 
does, but I dont know enough to know for sure). So you could ask 
"which {commit,tag,signature,tree}(s) refer(s) to this object?" - 
that general concept will always work. If you wanted to make the 
implementation of this index use some kind of sub directory as in the 
above, fine..

See also method 2 above. Which would be more efficient for tools if, 
within a project, some developers sign their 'updates' and some 
dont.. (you never need to check whether there's a signature or not - 
you'll know it from the URI automatically).

> 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).

Indeed.

Anyway, we shall see what Linus does. :)

(But I do hope at least that signatures are /not/ included inline 
using BEGIN PGP.. in the object that is signed.)

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
To err is human, to purr feline.
To err is human, two curs canine.
To err is human, to moo bovine.