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 1RLdQe-0007Yj-QL for garchives@archives.gentoo.org; Wed, 02 Nov 2011 16:12:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9C46821C057; Wed, 2 Nov 2011 16:12:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1C18121C060 for ; Wed, 2 Nov 2011 16:11:55 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8595E1B401E for ; Wed, 2 Nov 2011 16:11:54 +0000 (UTC) Received: (qmail 13617 invoked by uid 10000); 2 Nov 2011 16:11:54 -0000 Date: Wed, 2 Nov 2011 16:11:54 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Manifest signing Message-ID: References: <4E848879.2050100@gentoo.org> <4EB13189.4000500@groeper-berlin.de> 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=us-ascii Content-Disposition: inline In-Reply-To: <4EB13189.4000500@groeper-berlin.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 104e105d-2e3b-4dc6-b681-9979d6e6ae7a X-Archives-Hash: 240ec8fe4c03e9969d7b3120df079d46 On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gentoo@groeper-berlin.de wrote: > I followed the threads about manifest signing with interest and even had > a look at the manifest signing guide [4]. Sounds nice at first view. > But, please correct me, if I'm wrong. I didn't find a place where these > signatures are verified. > Is manifest signing for the infrastructure team, enabling them to verify > the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by > commit signing if the move to git is done ([2])? Developer signing is radically altered in the face of git yes, that's one of the reasons not much has happened there. But the other larger reason is that developer signing pales in importance to the signature chain between infra->user. > If it is (also) for the users, why is there no code for it in portage > anymore [3]? Hmm, I hadn't see that removal, but it makes sense unless the entire tree is developer-signed, which isn't likely to happen soon. > Okay "why" is clear. Obviously nobody was maintaining it... The code worked when I used it... > I thought about signing the manifests of my overlay. But this is > senseless, if there is no automatic check. I can't think of any user > verifying manifest signatures by hand. There's a chicken & egg problem with most signing. You need to communicate the valid keys out of band from the actual repo. Maybe the layman data is a good place for that, but until such a location is figured out, you have zero security gain (if the 'correct' keys are only listed in a file in the repo, any attacker just replaces that when he puts his other content in). > How does infrastructure team check, if a GPG key belongs to a developer? > The Manifest signing guide [4] simply says "Upload the key to a > keyserver". Everbody can upload a key to the public keyservers. An > attacker, able to modify a signed Manifest, could simply create a new > key on the developers name and use it to sign the modified manifest. > Therefore it must be clear which key really belongs to a dev. Developers specify in their LDAP data what keys are theirs, and this gets exported here, amongst other places: http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml There was a prototype keyserver at one point as well, and I can generate new keyrings if needed based on the LDAP data. > Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. > This looks like the right place to continue work on Tree Signing. Those were the draft copies, which were finalized into GLEP 57..61. You are correct that there are two unfinished GLEPs in that directory: 02-developer-process-security 03-gnupg-policies-and-handling Of those, 03 can probably be written at this point. 02 is going to change radically when git comes into play. -- 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