Re: Git-commits mailing list feed.

From: Paul Jakma
Date: Sun Apr 24 2005 - 20:38:56 EST

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

3b128932189018329839019 <- object to sign
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).


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

Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
To err is human, to purr feline.
To err is human, two curs canine.
To err is human, to moo bovine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at