1 |
Hi, |
2 |
|
3 |
Am 02.11.2011 17:11, schrieb Robin H. Johnson: |
4 |
> On Wed, Nov 02, 2011 at 01:03:21PM +0100, enno+gentoo@××××××××××××××.de wrote: |
5 |
>> I followed the threads about manifest signing with interest and even had |
6 |
>> a look at the manifest signing guide [4]. Sounds nice at first view. |
7 |
>> But, please correct me, if I'm wrong. I didn't find a place where these |
8 |
>> signatures are verified. |
9 |
>> Is manifest signing for the infrastructure team, enabling them to verify |
10 |
>> the author of a commit (see GLEP57 [1])? Wouldn't this be obsoleted by |
11 |
>> commit signing if the move to git is done ([2])? |
12 |
> Developer signing is radically altered in the face of git yes, that's |
13 |
> one of the reasons not much has happened there. But the other larger |
14 |
> reason is that developer signing pales in importance to the signature |
15 |
> chain between infra->user. |
16 |
If developer signing works, it could act as a trust chain between |
17 |
(developer->)infra->user. And it could work with good old default |
18 |
"emerge --sync", not only with emerge-webrsync and snapshots. |
19 |
If its senseless to do anything in this area as long as the move to git |
20 |
isn't done, there is no need to wine about unsigned manifests. |
21 |
At least if there isn't anyone checking developer signatures at the moment. |
22 |
|
23 |
>> If it is (also) for the users, why is there no code for it in portage |
24 |
>> anymore [3]? |
25 |
> Hmm, I hadn't see that removal, but it makes sense unless the entire |
26 |
> tree is developer-signed, which isn't likely to happen soon. |
27 |
I don't agree here. Of course the implementation shouldn't stop the user |
28 |
from installing an unsigned package at the moment. But it could give a |
29 |
warning instead and ask the user what to do. |
30 |
In this way developers are encouraged to sign their packages (to make |
31 |
the warning go away) and users get the ability to check the signatures, |
32 |
that already exist. |
33 |
Key problem here is the Gentoo keyring (how to ensure it didn't get |
34 |
manipulated). |
35 |
|
36 |
>> Okay "why" is clear. Obviously nobody was maintaining it... |
37 |
> The code worked when I used it... |
38 |
I didn't check it. All I have are the commit messages and the |
39 |
feature-removal of the portage team. |
40 |
|
41 |
>> I thought about signing the manifests of my overlay. But this is |
42 |
>> senseless, if there is no automatic check. I can't think of any user |
43 |
>> verifying manifest signatures by hand. |
44 |
> There's a chicken & egg problem with most signing. You need to |
45 |
> communicate the valid keys out of band from the actual repo. |
46 |
> Maybe the layman data is a good place for that, but until such a |
47 |
> location is figured out, you have zero security gain (if the 'correct' |
48 |
> keys are only listed in a file in the repo, any attacker just replaces |
49 |
> that when he puts his other content in). |
50 |
Of course. But security is always worth thinking about it. |
51 |
First step: What are the possibilities the check the signatures? FAIL. |
52 |
In my case some (most?) of the users of my overlay should know my GPG |
53 |
key already. The web of trust works here. The drawback for possible |
54 |
other users would be a false sense of security. |
55 |
|
56 |
>> How does infrastructure team check, if a GPG key belongs to a developer? |
57 |
>> The Manifest signing guide [4] simply says "Upload the key to a |
58 |
>> keyserver". Everbody can upload a key to the public keyservers. An |
59 |
>> attacker, able to modify a signed Manifest, could simply create a new |
60 |
>> key on the developers name and use it to sign the modified manifest. |
61 |
>> Therefore it must be clear which key really belongs to a dev. |
62 |
> Developers specify in their LDAP data what keys are theirs, and this |
63 |
> gets exported here, amongst other places: |
64 |
> http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml |
65 |
Thanks for the enlightenment. But I doubt, if this should be the way to |
66 |
go (see below). |
67 |
|
68 |
> There was a prototype keyserver at one point as well, and I can generate |
69 |
> new keyrings if needed based on the LDAP data. |
70 |
This could be okay for a first creation. Later I would prefer something |
71 |
like Debian does: |
72 |
http://keyring.debian.org/replacing_keys.html |
73 |
That way you would decouple the LDAP and the keyring and trust only the |
74 |
data, that is already in the keyring (somebody whose key is already in |
75 |
the keyring signing the request for a new key). |
76 |
See also: http://keyring.debian.org/ |
77 |
Perhaps the prototype keyserver already did something like that. |
78 |
|
79 |
> |
80 |
>> Furthermore the Tree-Signing-GLEPs [5] seem to be incomplete. |
81 |
>> This looks like the right place to continue work on Tree Signing. |
82 |
> Those were the draft copies, which were finalized into GLEP 57..61. |
83 |
> You are correct that there are two unfinished GLEPs in that directory: |
84 |
> 02-developer-process-security |
85 |
> 03-gnupg-policies-and-handling |
86 |
> |
87 |
> Of those, 03 can probably be written at this point. |
88 |
> 02 is going to change radically when git comes into play. |
89 |
I had those 2 in mind, yes. |
90 |
|
91 |
Regards, |
92 |
Enno |