Re: Git-commits mailing list feed.

[Paul Jakma]

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
  object

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.

Possibly.

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

regards,
--
Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
Fortune:
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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/