Re: Git-commits mailing list feed.

From: Paul Jakma
Date: Sun Apr 24 2005 - 22:07:55 EST

On Sun, 24 Apr 2005, David A. Wheeler wrote:

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.

Well, i'm trying to play with git right now to see what would fit with how it abstracts things.

I think possibly:

- add the 'signature object' to the respository after the signed

So a 'signed commit' turns into the

- tool preparing the commit object,
- get the user to sign it
- save the detached signature for later
- adding the commit object to the repository
- prepare the signing object and add to repository

The repository head then refers then to signature object, which could (handwaving) look something like:

Object Signature
Signing <object ID, in this case of the commit object>
Sign-type GPG

<signature data>

Tools should then treat signature objects as 'stand ins' for the object they are signing (verify the signature - if desired - and then just retrieve the 'Signing' object ID and use that further).

I have no working knowledge of git though, other than following this list. So I have no idea whether above is at all appropriate or workable.

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.

No more lost than anything else in the git 'fs'.

If someone prunes old objects, they'll lose the signed objects along with the signatures. If those files weren't replicated anywhere else, well they've just blown away history for good, both the history of the source and corresponding signatures.

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.

See above.

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

Well, it could be retained then.

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.

In CVS it is. If you 'cvs log' a file, you can get a report on which revisions of the file belong to which tags (which can be useful information sometimes: "ah, so that release had the buggy version" type of thing. Or as a sanity check to make sure you got a tag right - particularly when you have to move a wrong tag[1]). So, in addition to signatures, a general 'referrers of this object' index could be useful for reports.

1. This might be just a CVS thing, and not wanted for git -> the ability to tag historical revisions and indeed change what tags refer to.

Paul Jakma paul@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
Decaffeinated coffee? Just Say No.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at