Re: Git-commits mailing list feed.

[David A. Wheeler]

Linus Torvalds wrote:
> 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).
>
> Actually, if we do totally separate files, then the detached thing is ok, 
> and we migth decide to not call the objects at all, since that seems to be 
> unnecessarily complex.
>
> Maybe we'll just have signed tags by doing exactly that: just a collection 
> of detached signature files. The question becomes one of how to name such 
> things in a distributed tree. That is the thing that using an object for 
> them would have solved very naturally.

I agree, naming signatures using the same way other objects are named
would be very clean.  So, why not? It's perfectly reasonable to
just store detached signatures as hashed objects, just like the rest;
just create a new object type ("signature").
If 3 different keys are used to sign the same object, the detached
signatures will have different hash values, so they'll get named easily.

Now you just have to FIND the signature of a signed object,
i.e. efficiently go the "other way" from signed object to detached
signature.  A separate directory with this mapping, or embedding the
mapping inside the object directory (HASH.d/<list>) both solve it.

The more I think about it, the more I think a separate "reverse"
index directory would be a better idea. It just needs to from
"me" to "who references me", at least so that you can quickly
find all signatures of a given object. If the reverse directory
gets wonky, anyone can just delete the reverse index directory
at any time & reconstruct it by iterating the objects.
Before "-----BEGIN PGP SIGNATURE-----" you should add:
 signatureof HASHVALUE
to make reconstruction easy; PGP processors ignore stuff
before "-----".  The PGP data does include a hash, but it's not
easy to get it out (I don't see a way to do it in gpg from the
command line), and it's quite possible that a signer won't
use SHA-1 when they sign something (they may not even
realize it; it depends on their implementation's configuration).
Better to include something about what was signed with the signature.

Hmm, probably worth backtracking to see what's needed.
There needs to be a way to identify tags, and a way to sign that
tag so that you can decide to trust some tags & not others.
There needs to be a way to sign commits, and store that info
for later.  And really, these are special cases of general
assertions about other things; you might want someone to be
able to make other signed assertions (e.g., that it
passed test suite XYZ).

If tags & commits are all you plan to sign for now, well, you
already have commits.  You can just add a "tag" type and a
"signature" type of object (the "signature" is just a detached
OpenPGP signature).  "signature" can sign tag or commit types.
I still like the idea of a more general "assertion" type, esp.
for assertions that something passed a test suite on a certain date
or was reviewed at a certain date by someone, but admittedly
that could be added later in the same manner.

Then you need to be able to quickly find a signature, given a
commit or tag.  A "reverse" directory then does that nicely,
and if you put enough information in front of the signature,
you can regenerate the reverse directory whenever you wish.

--- David A. Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/