| 1 |
On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gentoo@××××××××××××××.de wrote: |
| 2 |
> I followed the threads about manifest signing with interest and even had |
| 3 |
> a look at the manifest signing guide [4]. Sounds nice at first view. |
| 4 |
> But, please correct me, if I'm wrong. I didn't find a place where these |
| 5 |
> signatures are verified. |
| 6 |
> Is manifest signing for the infrastructure team, enabling them to verify |
| 7 |
> the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by |
| 8 |
> commit signing if the move to git is done ([2])? |
| 9 |
Developer signing is radically altered in the face of git yes, that's |
| 10 |
one of the reasons not much has happened there. But the other larger |
| 11 |
reason is that developer signing pales in importance to the signature |
| 12 |
chain between infra->user. |
| 13 |
|
| 14 |
> If it is (also) for the users, why is there no code for it in portage |
| 15 |
> anymore [3]? |
| 16 |
Hmm, I hadn't see that removal, but it makes sense unless the entire |
| 17 |
tree is developer-signed, which isn't likely to happen soon. |
| 18 |
|
| 19 |
> Okay "why" is clear. Obviously nobody was maintaining it... |
| 20 |
The code worked when I used it... |
| 21 |
|
| 22 |
> I thought about signing the manifests of my overlay. But this is |
| 23 |
> senseless, if there is no automatic check. I can't think of any user |
| 24 |
> verifying manifest signatures by hand. |
| 25 |
There's a chicken & egg problem with most signing. You need to |
| 26 |
communicate the valid keys out of band from the actual repo. |
| 27 |
Maybe the layman data is a good place for that, but until such a |
| 28 |
location is figured out, you have zero security gain (if the 'correct' |
| 29 |
keys are only listed in a file in the repo, any attacker just replaces |
| 30 |
that when he puts his other content in). |
| 31 |
|
| 32 |
> How does infrastructure team check, if a GPG key belongs to a developer? |
| 33 |
> The Manifest signing guide [4] simply says "Upload the key to a |
| 34 |
> keyserver". Everbody can upload a key to the public keyservers. An |
| 35 |
> attacker, able to modify a signed Manifest, could simply create a new |
| 36 |
> key on the developers name and use it to sign the modified manifest. |
| 37 |
> Therefore it must be clear which key really belongs to a dev. |
| 38 |
Developers specify in their LDAP data what keys are theirs, and this |
| 39 |
gets exported here, amongst other places: |
| 40 |
http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml |
| 41 |
|
| 42 |
There was a prototype keyserver at one point as well, and I can generate |
| 43 |
new keyrings if needed based on the LDAP data. |
| 44 |
|
| 45 |
> Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. |
| 46 |
> This looks like the right place to continue work on Tree Signing. |
| 47 |
Those were the draft copies, which were finalized into GLEP 57..61. |
| 48 |
You are correct that there are two unfinished GLEPs in that directory: |
| 49 |
02-developer-process-security |
| 50 |
03-gnupg-policies-and-handling |
| 51 |
|
| 52 |
Of those, 03 can probably be written at this point. |
| 53 |
02 is going to change radically when git comes into play. |
| 54 |
|
| 55 |
|
| 56 |
-- |
| 57 |
Robin Hugh Johnson |
| 58 |
Gentoo Linux: Developer, Trustee & Infrastructure Lead |
| 59 |
E-Mail : robbat2@g.o |
| 60 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives