Re: Git-commits mailing list feed.
- From
- Paul Jakma <paul@clubi.ie>
- Date
- Apr 25, 2005, 01:35 UTC
- Message-ID
- <Pine.LNX.4.62.0504250212200.14200@sheen.jakma.org>
- In-Reply-To
- <426C4168.6030008@dwheeler.com>
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.:
Show 6 quoted lines
> 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).
Show 5 quoted lines
> 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.