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 1Q3zyA-0008HE-BW for garchives@archives.gentoo.org; Mon, 28 Mar 2011 00:06:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE4171C07F; Mon, 28 Mar 2011 00:05:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A70581C066 for ; Mon, 28 Mar 2011 00:05:22 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id E165E1B4050 for ; Mon, 28 Mar 2011 00:05:21 +0000 (UTC) Received: (qmail 25868 invoked by uid 10000); 28 Mar 2011 00:05:20 -0000 Date: Mon, 28 Mar 2011 00:05:20 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: rejecting unsigned commits Message-ID: References: <201103252133.27978.dilfridge@gentoo.org> <201103261012.17119.dilfridge@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X+8siUETKMkW99st" Content-Disposition: inline In-Reply-To: <201103261012.17119.dilfridge@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: 2390f819c3f822112eeb69236b784ff0 --X+8siUETKMkW99st Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: > 3) Rely on an existing key list somewhere distributed in portage; the lis= t=20 =2E.. > Cons: Mainly that the key id is a pretty short hash afaik.(Any better-inf= ormed=20 > people around?) You can use the long-format key IDs if you want. 0xB27B944E34884E85 is my long-form key. > Am I missing something? In my tree-signing GLEPs, I explicitly pointed out that the developer signing of content only had real value for the developer->CVS part of the chain. Specifically, that while building the rsync tree for distribution, we can verify that the content we are preparing was indeed =66rom a developer. Please re-read GLEP57. Everything in this thread been attempting to apply solutions to 'Process #1' (developer->infrastructure) to provide direct security for the end user after 'Process #2' (infrastructure->mirrors->users). What can we be certain of? 1. Developers should be signing manifests. 2. Infrastructure should be verifying those commits before pushing out to rsync. 3. Regardless of their choice of rsync or websync, users need to be able to verify that the tree that left Infrastructure was not modified in transit. RegI see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole:=20 =3D=3D=3D Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. =3D=3D=3D Is this the easiest attack? No, certainly not, looking at mirrors mirror, potentially a running deliberate selective malicious mirror would be much easier. --=20 Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --X+8siUETKMkW99st Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iEYEARECAAYFAk2P0MAACgkQPpIsIjIzwiwE9QCg+2tZ8p/PLkIeNwuBfXdScBdW SdQAoJF7OuN+9ZCkn924ZJD/qsdtmKWp =rmTF -----END PGP SIGNATURE----- --X+8siUETKMkW99st--