Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262445AbVDYCMF (ORCPT ); Sun, 24 Apr 2005 22:12:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262451AbVDYCMF (ORCPT ); Sun, 24 Apr 2005 22:12:05 -0400 Received: from aibo.runbox.com ([193.71.199.94]:59294 "EHLO cujo.runbox.com") by vger.kernel.org with ESMTP id S262445AbVDYCLx (ORCPT ); Sun, 24 Apr 2005 22:11:53 -0400 Message-ID: <426C5266.6050200@dwheeler.com> Date: Sun, 24 Apr 2005 22:13:58 -0400 From: "David A. Wheeler" Reply-To: dwheeler@dwheeler.com User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma CC: Linus Torvalds , Sean , Thomas Glanzmann , David Woodhouse , Jan Dittmer , Greg KH , Kernel Mailing List , Git Mailing List Subject: Re: Git-commits mailing list feed. References: <200504210422.j3L4Mo8L021495@hera.kernel.org> <42674724.90005@ppp0.net> <20050422002922.GB6829@kroah.com> <426A4669.7080500@ppp0.net> <1114266083.3419.40.camel@localhost.localdomain> <426A5BFC.1020507@ppp0.net> <1114266907.3419.43.camel@localhost.localdomain> <20050423175422.GA7100@cip.informatik.uni-erlangen.de> <2911.10.10.10.24.1114279589.squirrel@linux1> <426C4168.6030008@dwheeler.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2638 Lines: 59 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. >> 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 - 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/