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 |