From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14394 invoked from network); 1 May 2004 11:09:02 +0000 Received: from smtp.gentoo.org (128.193.0.39) by eagle.gentoo.oregonstate.edu with DES-CBC3-SHA encrypted SMTP; 1 May 2004 11:09:01 +0000 Received: from lists.gentoo.org ([128.193.0.34] helo=eagle.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.24) id 1BJsMf-0003Xz-TK for arch-gentoo-dev@lists.gentoo.org; Sat, 01 May 2004 11:09:01 +0000 Received: (qmail 26151 invoked by uid 50004); 1 May 2004 11:09:01 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 1456 invoked from network); 1 May 2004 11:09:01 +0000 From: Chris Bainbridge To: gentoo-dev@lists.gentoo.org Date: Sat, 1 May 2004 12:09:02 +0100 User-Agent: KMail/1.6.1 References: <1083296558.8842.127.camel@woot.uberdavis.com> <1083351681.8842.145.camel@woot.uberdavis.com> <20040430222338.327af167@sven.genone.homeip.net> In-Reply-To: <20040430222338.327af167@sven.genone.homeip.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405011209.02935.C.J.Bainbridge@ed.ac.uk> X-OriginalArrivalTime: 01 May 2004 11:09:01.0878 (UTC) FILETIME=[B55A3D60:01C42F6C] Subject: Re: [gentoo-dev] Key policy for GPG verification [was: 2004.2 Feature Requests] X-Archives-Salt: 8b2e4157-a92e-455f-a173-155db5127563 X-Archives-Hash: 90059f1668b5eda7bcf43e863e6904e9 On Friday 30 April 2004 21:23, Marius Mauch wrote: > Ok, guess I should repeat that the most important thing for GPG signing > (actually the missing part is verification) that's still missing is a > key policy: where to store keys, how to check if they are trustworthy > and so on. If we can agree on a simple and effective solution there it > shouldn't be too difficult to implement this feature (talking about code > here, not the tree). The last time we had a way too long thread with way > too many details and discussions about problem scenarios, please let's > try to avoid that. > And to get everyone on track I'll start with a very simple proposal > (idea stolen from Spanky IIRC), I won't say that it's really effective > though: > - keys are stored in a keyring and are installed by an ebuild > - a key is trustworthy if it is in that keyring > - expiration is handled by removing the key from that keyring > - each modification to the keyring involves a version bump on the ebuild > That's about the easiest for implementation and doesn't require anything > new for our infrastructure or key-signing-sessions. It does not say who > will manage that keyring though as that is not important for the > implementation. I'm pretty sure that the idea has a number of flaws, but > we have to start somewhere. > > Marius Uh oh.. this again ;-) The above proposal doesn't allow recovery from a compromise, since someone could update the new keys ebuild to a new one containing only their key. The master key / monthly signing multi-server keys proposal was better. See the archives for details. -- gentoo-dev@gentoo.org mailing list