lkml.org 
[lkml]   [2005]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Git-commits mailing list feed.
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@clubi.ie paul@jakma.org 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-25 05:10    [W:0.085 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site