lkml.org 
[lkml]   [2005]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 25 Apr 2005 02:35:45 +0100 (IST)
FromPaul Jakma <>
SubjectRe: Git-commits mailing list feed.
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.
-
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/

\
 
 \ /
  Last update: 2005-04-25 03:41    [from the cache]
©2003-2010