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 1Q4074-0000in-Rz for garchives@archives.gentoo.org; Mon, 28 Mar 2011 00:15:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9FA071C07F; Mon, 28 Mar 2011 00:15:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 565DA1C07F for ; Mon, 28 Mar 2011 00:13:50 +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 94F381B402E for ; Mon, 28 Mar 2011 00:13:49 +0000 (UTC) Received: (qmail 26941 invoked by uid 10000); 28 Mar 2011 00:13:48 -0000 Date: Mon, 28 Mar 2011 00:13:48 +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="h22Fi9ANawrtbNPX" 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: e0a62fca298b768e92f8a76c5c0e86a7 --h22Fi9ANawrtbNPX 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 > file with the key id's (not the keys themselves) is signed with a master = key. > Is a mediocre and potentially insecure workaround. > Pros: you can exactly decide what keys are used and trusted, without thin= king=20 > about GnuPG's inner workings. A user can edit his key and the key remains= =20 > trusted. > Cons: Mainly that the key id is a pretty short hash afaik.(Any better-inf= ormed=20 > people around?) 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) 2. Clear-sign L, produces L' 3. Include L' in /metadata/ during rsync content build. 3.1. Provide all L' files in a trusted Git repository for historical refere= nce. 4. Tree-sign per GLEP58, such that signed list is included. Pros: - L' is plaintext and works well w/ rsync deltas. Security weakpoints: - Introduces new weak point if attacker can compromise the automated clear-signing service of #2. > 4) Rely on an existing list of keys somewhere distributed in portage and= =20 > possibly somewhere else (keyservers); a key userid is signed with a maste= r=20 > key. Work with GnuPG's well-tested and well-thought-out trust relationshi= ps. > Back to start, time to re-read the entire thread... :) What does this actually add over #3 in terms of security? --=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 --h22Fi9ANawrtbNPX 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. iEYEARECAAYFAk2P0rwACgkQPpIsIjIzwiyiGQCfSdz+izIZE/tnbSduBVKaBgqJ qM0AoPzcQS9tNR25NJX1cTdlDftsfa/s =nRK7 -----END PGP SIGNATURE----- --h22Fi9ANawrtbNPX--