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]