Re: Git-commits mailing list feed.

From: David A. Wheeler <dwheeler@dwheeler.com>
Date: Apr 25, 2005, 03:08 UTC
Message-ID: <426C5F43.8010705@dwheeler.com>
In-Reply-To: <Pine.LNX.4.58.0504241846290.18901@ppc970.osdl.org>

Linus Torvalds wrote:

Show 14 quoted lines

> 
> 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