Re: [gentoo-dev] Manifest signing
Hi, Am 02.11.2011 17:11, schrieb Robin H. Johnson: On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gen...@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 developer signing works, it could act as a trust chain between (developer-)infra-user. And it could work with good old default emerge --sync, not only with emerge-webrsync and snapshots. If its senseless to do anything in this area as long as the move to git isn't done, there is no need to wine about unsigned manifests. At least if there isn't anyone checking developer signatures at the moment. 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. I don't agree here. Of course the implementation shouldn't stop the user from installing an unsigned package at the moment. But it could give a warning instead and ask the user what to do. In this way developers are encouraged to sign their packages (to make the warning go away) and users get the ability to check the signatures, that already exist. Key problem here is the Gentoo keyring (how to ensure it didn't get manipulated). Okay why is clear. Obviously nobody was maintaining it... The code worked when I used it... I didn't check it. All I have are the commit messages and the feature-removal of the portage team. 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). Of course. But security is always worth thinking about it. First step: What are the possibilities the check the signatures? FAIL. In my case some (most?) of the users of my overlay should know my GPG key already. The web of trust works here. The drawback for possible other users would be a false sense of security. 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 Thanks for the enlightenment. But I doubt, if this should be the way to go (see below). There was a prototype keyserver at one point as well, and I can generate new keyrings if needed based on the LDAP data. This could be okay for a first creation. Later I would prefer something like Debian does: http://keyring.debian.org/replacing_keys.html That way you would decouple the LDAP and the keyring and trust only the data, that is already in the keyring (somebody whose key is already in the keyring signing the request for a new key). See also: http://keyring.debian.org/ Perhaps the prototype keyserver already did something like that. 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. I had those 2 in mind, yes. Regards, Enno signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest signing
On Thu, Nov 03, 2011 at 10:55:52PM +0100, enno+gen...@groeper-berlin.de wrote: 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. I don't agree here. Of course the implementation shouldn't stop the user from installing an unsigned package at the moment. But it could give a warning instead and ask the user what to do. In this way developers are encouraged to sign their packages (to make the warning go away) and users get the ability to check the signatures, that already exist. Key problem here is the Gentoo keyring (how to ensure it didn't get manipulated). Distributing the keyring itself signed is how Debian does it IIRC. 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). Of course. But security is always worth thinking about it. First step: What are the possibilities the check the signatures? FAIL. In my case some (most?) of the users of my overlay should know my GPG key already. The web of trust works here. The drawback for possible other users would be a false sense of security. That's why I say the gpg key should be in the layman data. Overlays team, do you think this is reasonable? There was a prototype keyserver at one point as well, and I can generate new keyrings if needed based on the LDAP data. This could be okay for a first creation. Later I would prefer something like Debian does: http://keyring.debian.org/replacing_keys.html That way you would decouple the LDAP and the keyring and trust only the data, that is already in the keyring (somebody whose key is already in the keyring signing the request for a new key). See also: http://keyring.debian.org/ Perhaps the prototype keyserver already did something like that. The Debian model was discussed, and the main problem was finding enough people to sign the keys near all of the devs, esp. if you require meeting in person. You need two factors to be able to change your GPG key on file anyway. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Manifest signing
Hello, Am 29.09.2011 17:02, schrieb Anthony G. Basile: Hi everyone, The issue of Manifest signing came up in #gentoo-hardened channel ... again. Its clearly a security issue and yet many manifests in the tree are still not signed. Is there any chance that we can agree to reject unsigned manifests? Possibly a question for the Council to adjudicate? 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])? If it is (also) for the users, why is there no code for it in portage anymore [3]? Okay why is clear. Obviously nobody was maintaining 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. To me it looks like there are repeating complaints about missing signatures, but I don't see any verification methods for existing manifest signatures. At the moment there are 10608 of 15085 manifests signed in my portage tree. But I can't check them, because I don't have the public keys and if I fetch them from a public keyserver, I still don't know, if they really belong to the corresponding Gentoo developers. Is there some kind of Gentoo Keyring I don't know of? 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. Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. This looks like the right place to continue work on Tree Signing. Regards, Enno [1] http://www.gentoo.org/proj/en/glep/glep-0057.html [2] http://archives.gentoo.org/gentoo-dev/msg_91813ec042831af2fd688e7ecfae4943.xml [3] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c16649d121dca977b3c569f03c5d1b194b635d4 [4] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 [5] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/robbat2/tree-signing-gleps/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Manifest signing
On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gen...@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 : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Manifest signing
On 29/09/11 16:02, Anthony G. Basile wrote: Is there any chance that we can agree to reject unsigned manifests? Possibly a question for the Council to adjudicate? I am happy to back a mandatory signing policy for the main gentoo-x86 tree. This is a simple yes or no question that the council can vote on. Regards, Tony V.
Re: [gentoo-dev] Manifest signing
On 29-09-2011 11:02:17 -0400, Anthony G. Basile wrote: The issue of Manifest signing came up in #gentoo-hardened channel ... again. Its clearly a security issue and yet many manifests in the tree are still not signed. Is there any chance that we can agree to reject unsigned manifests? Possibly a question for the Council to adjudicate? Please refer to Mike's thread on this. http://archives.gentoo.org/gentoo-dev/msg_7210bc8a18140db8f18ff89245efacd5.xml -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
