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 1NFHXJ-00087S-K3 for garchives@archives.gentoo.org; Tue, 01 Dec 2009 01:28:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1B14AE066B; Tue, 1 Dec 2009 01:27:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C5291E066B for ; Tue, 1 Dec 2009 01:27:43 +0000 (UTC) Received: from mail.isohunt.com (b01.ext.isohunt.com [208.71.112.51]) by smtp.gentoo.org (Postfix) with ESMTP id CECBD679C2 for ; Tue, 1 Dec 2009 01:27:42 +0000 (UTC) Received: (qmail 18035 invoked from network); 1 Dec 2009 01:27:42 -0000 Received: from tsi-static.orbis-terrarum.net (HELO grubbs.orbis-terrarum.net) (76.10.188.108) by mail.isohunt.com (qpsmtpd/0.33-dev on beta01) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 01 Dec 2009 01:27:42 +0000 Received: (qmail 7748 invoked by uid 10000); 1 Dec 2009 01:27:40 -0000 Date: Tue, 1 Dec 2009 01:27:40 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting) Message-ID: References: <7c612fc60911251350k3560b7d7sf4e9c867a30b0d90@mail.gmail.com> <20091130113051.GA32489@chopin.edu.pl> <4B14369D.1040608@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="ey/N+yb7u/X9mFhi" Content-Disposition: inline In-Reply-To: <4B14369D.1040608@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 1f4ea089-93c9-4f02-a1d0-ce3c8ba3595e X-Archives-Hash: 81cc6a299116d4040b70294fa62581b5 --ey/N+yb7u/X9mFhi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 30, 2009 at 04:18:21PM -0500, Richard Freeman wrote: > Antoni Grzymala wrote: > >How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort > >a year ago to summarize the then-current state of things regarding tree > >and package signing, however the matter seems to have lain idle and > >untouched for more than a year since. > One concern I have with the GLEP-57 is that it is a bit hazy on some > of the implementation details, and the current implementation has > some weaknesses. GLEP57 is purely informational. The GLEP on Individual developer signing has not made it into a Draft yet. But you can view the very brief version here: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-glep= s/02-developer-process-security?view=3Dmarkup > I go ahead and sign my commits. However, when I do this I'm signing > the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at > best I've tested that one particular version of that package works > fine for me. My signature applies to ALL versions of the package > even though I haven't tested those. This was covered in the draft linked above. A larger discussion on it is welcome, as while both competing options exist, neither has a clear advantage over the other. > Now, if we had an unbroken chain of custody then that wouldn't be a > problem. However, repoman commit doesn't enforce this and the > manifest file doesn't really contain any indication of what packages > are assured to what level of confidence. Chain of custody from infrastructure to user is covered in GLEP58 (MetaManifest). > If we want to sign manifests then the only way I see it actually > providing real security benefits is if either: >=20 > 1. The distro does this in the background in some way in a secure > manner (ensuring it happens 100% of the time). See GLEP58. > 2. Every developer signs everything 100% of the time (make it a QA > check). +1 on this. > The instant you have a break in the signature chain you can > potentially have a modification. If somebody cares enough to check > signatures, then they're going to care that the signature means > something. Otherwise it only protects against accidental > modifications, and the hashes already provide pretty good protection > against this. GLEP60 covers the Manifest2 filetypes and better logic on which missing/mismatches should be considered as fatal. --=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 --ey/N+yb7u/X9mFhi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (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. iEYEARECAAYFAksUcQwACgkQPpIsIjIzwiyCxQCg2adzrOpeQF1ZUV8TukHMBpIU IkMAoJUJ3ixvWbQmhSH5JCrk8JGJe/DL =WvpF -----END PGP SIGNATURE----- --ey/N+yb7u/X9mFhi--