Re: Git-commits mailing list feed.

From: David A. Wheeler <dwheeler@dwheeler.com>
Date: Apr 25, 2005, 02:13 UTC
Message-ID: <426C5266.6050200@dwheeler.com>
In-Reply-To: <Pine.LNX.4.62.0504250212200.14200@sheen.jakma.org>

Paul Jakma wrote:

> On Sun, 24 Apr 2005, David A. Wheeler wrote:
> Hmm, what do you mean by "repeating what gets signed"?

Forget it, irrelevant.  I vaguely remembered some problem with
gpg's detached signatures, but it was probably either a really
early alpha version or someone was using "--clearsign" instead
of "--armor".  I just did a quick check with:
  gpg --armor --detach -o junk.sig junk.c
and it worked "as expected"; no repeat of the data.

Show 6 quoted lines

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

Right. I suggested putting it in the same directory as the objects, so that rsync users get them "for free", but a separate directory has its own advantages & that'd be fine too. In fact, the more I think about it, I think it'd be cleaner to have it separate. You could prepend on top of the signature (if signatures are separate from assertions) WHAT got signed so that the index could be recreated from scratch when desired.

> 2. Just give people the URI of the signature, let them (or their
>    tools) follow the 'parent' link to the object of interest

If you mean "the signatures aren't stored with the objects", NO. Please don't! If the signatures are not stored in the database, then over time they'll get lost. It's important to me to store the record of trust, as well as what changed, so that ANYONE can later go back and verify that things are as they're supposed to be, or exactly who trusted what.

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

git definitely doesn't have this currently, though you could run the fsck tools which end up creating a lot of the info (but it's then thrown away).

 > So you could ask "which

> {commit,tag,signature,tree}(s) refer(s) to this object?" - that general 
> concept will always work.

Yes. The problem is that maintaining the index is a pain. It's probably worth it for signatures, because the primary use is the other direction ("who signed this?"); it's not clear that the other direction is common for other data.

--- David A. Wheeler