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 [email protected] [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]