Re: Git-commits mailing list feed.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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	[email protected]	[email protected]	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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux