1 |
>On Thursday 24 April 2003 3:10 pm, Joshua Brindle wrote: |
2 |
> |
3 |
>> >Will there be provision for controlling which developers are authorised to |
4 |
>> >sign each package, or will portage allow any developer to sign any package |
5 |
>> >manifest? |
6 |
>> |
7 |
>> there is no easy way since the only way cvs knows to allow/disallow commits |
8 |
>> is by permissions, we use permissions but they aren't fine grained, ie: |
9 |
>> everyone who has access to commit any package can commit to all of them. |
10 |
>> This is a lot better anyway since we have to be able to add new packages, |
11 |
>> do quick bumps on packages we don't necessarilly maintain, etc. Obviously |
12 |
>> if a dev is abusing we'll have records of what was commited and where and |
13 |
>> be able to take care of that. |
14 |
> |
15 |
>Consider this fictional scenario: A colleague is appointed a new gentoo |
16 |
>developer because of his interest in maintaining app-games/abcabcabcabc. I am |
17 |
>not interested in this package, and never intend to install it on our server |
18 |
>cluster. |
19 |
> |
20 |
>Do I have to worry about him planting trojan sys-libs/glibc ebuilds in our |
21 |
>local portage mirror? |
22 |
> |
23 |
|
24 |
Well, there isn't anything we can do on the client side. Users will always |
25 |
have the able to modify ebuilds/packages on their own machines |
26 |
or we'd have a lot of angry users. The one thing that would solve the |
27 |
problem is to 1) make sure you don't have any PORTDIR_OVERLAY's since |
28 |
those probably won't be verified by keys anyway (we may have a setting |
29 |
for this) and 2) emerge sync before you do _anything_, this means even |
30 |
emerge -s or emerge -p. |
31 |
|
32 |
Since an emerge sync would overwrite any changes in the local repository |
33 |
all your coworkers hard work got erased... |
34 |
|
35 |
Also: on my machine /usr/portage is writable only by root.. if the coworker |
36 |
has the access to write to the local tree then uhh, i don't guess it matters |
37 |
since he could just backdoor your system without using portage.. |
38 |
|
39 |
>Another way of looking at it........ |
40 |
> |
41 |
>If I understand correctly, your proposal is using signatures from an inner |
42 |
>keyring for two different purposes: |
43 |
>1. To confirm identity. This is the conventional meaning of a key signature, |
44 |
>as should be understood by everyone that signs someone elses key. |
45 |
>2. To confirm status. That is, to confirm that the owner of the key is an |
46 |
>official gentoo developer. |
47 |
> |
48 |
>Would it be better to use key signatures from the inner keyring only for the |
49 |
>first of those two purposes. Some file in portage, appropriately signed, |
50 |
>would list all official developers and the packages that they are authorised |
51 |
>to maintain. Senior gentoo developers will be authorised for everything. |
52 |
|
53 |
It would be impossible to keep the file accurate and up to date. Far too |
54 |
many devs are involved in lots of things, also we'd have to wait on the |
55 |
permissions key signer to even add new packages which would slow |
56 |
developmental efforts down dramatically. Most of the active developers |
57 |
don't stick to just a couple packages, they fix the bugs where they show |
58 |
up. I have personally edited a lot of the core packages, gcc, glibc, xfree, |
59 |
etc. It would have been a huge hassle if I had to go seek permission and |
60 |
justify it and wait for a decision, etc. |
61 |
|
62 |
We are, however, looking to set up a QA team after this signing setup is all |
63 |
implemented. The team would see every commit to cvs and verify that it |
64 |
is legitimate before allowing it into the public tree. There is talk of even allowing |
65 |
public submissions to this team to get user submitted ebuilds into the tree |
66 |
faster. We haven't yet discussed the logistics of the team or how the submission/ |
67 |
verification will work, but it's in the works... |
68 |
|
69 |
Joshua Brindle |
70 |
|
71 |
-- |
72 |
gentoo-hardened@g.o mailing list |