From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QGg0J-0003BU-BP for garchives@archives.gentoo.org; Sun, 01 May 2011 23:24:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A58921C0BB; Sun, 1 May 2011 23:24:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id E810A1C039 for ; Sun, 1 May 2011 23:24:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 723EB1B403E for ; Sun, 1 May 2011 23:24:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 required=5.5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozz0BBMtUMxh for ; Sun, 1 May 2011 23:23:57 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id C89BD1B403A for ; Sun, 1 May 2011 23:23:55 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QGfzV-0004jN-TN for gentoo-dev@gentoo.org; Mon, 02 May 2011 01:23:53 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 01:23:53 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 May 2011 01:23:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Devmanual text on ChangeLogs Date: Sun, 1 May 2011 23:23:40 +0000 (UTC) Message-ID: References: <4DBBCC6D.7080504@gentoo.org> <20110501100017.GE24801@gentoo.org> <20110501210831.GA2816@Eternity.halls.manchester.ac.uk> <20110501223325.GA3632@hrair> <20110501224906.GA4116@Eternity.halls.manchester.ac.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.134 (Wait for Me; GIT 9383aac branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 198eb1420b5dac6ab69bc8475e6ff4d8 Markos Chandras posted on Sun, 01 May 2011 23:49:06 +0100 as excerpted: > On Sun, May 01, 2011 at 03:33:25PM -0700, Brian Harring wrote: >> On Sun, May 01, 2011 at 10:08:31PM +0100, Markos Chandras wrote: >>> Since most ( if not all ) of us use the same message on the Changelog >>> and on the commit log, it probably worth the effort of having the >>> rsync servers create the Changelogs before populate the portage tree. >> This opens up a bit of nastyness; either the service would have to >> resign all manifests (which defeats a fair bit of the signing intent), >> or ChangeLog's would have to pulled in full from cvs, generated >> strictly server side (else manifest will have stale chksums for it), >> and ChangeLog will have to exist outside of all validation. > Thats a fair point but the way I see it we need to make a balanced > choice. Obviously is not feasible to have the rsync servers resign > everything. [But] having all the gpg keys on the rsync servers [...] > doesn't look that smart to me. > Leaving Changelogs unprotected might be a bit of a trouble but it > certainly is not that big a deal. Nothing serious can happen if someone > hijacks a plain text file. > In case people want to ensure end-to-end point integrity, we can use > a separate GPG key for the rsync server. However, this will make our GP= G > keys useless, and having a single key to sing 10.000 Manifest files doe= s > not look good either. What about having a dedicated server-based changlog-signing key? That's=20 still a lot of signing with a single key, but as you observed, the hazard= s=20 of a loss of integrity there aren't as high as with most of the tree=20 content. It'd require changes, but I don't believe they're out of line=20 with that required for the rest of the proposal. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman