1 |
* Chris Bainbridge (C.J.Bainbridge@×××××.uk) wrote: |
2 |
> Date: Thu, 25 Mar 2004 14:56:04 +0000 |
3 |
> From: Chris Bainbridge <C.J.Bainbridge@×××××.uk> |
4 |
> To: gentoo-dev@l.g.o |
5 |
> User-Agent: KMail/1.6.1 |
6 |
> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 |
7 |
> Subject: Re: [gentoo-dev] 2004.1 will not include a secure portage. |
8 |
> |
9 |
> On Thursday 25 March 2004 14:38, Jesse Nelson wrote: |
10 |
> > |
11 |
> > well if you move key verification into (or in addition to) the build |
12 |
> > process and make it aware of key servers. Invalidate a key on the |
13 |
> > keyserver and portage can refuse to build anything signed by DevX(or key X) |
14 |
> > or under pauls proposal a whole tree could be deemed untrusted. |
15 |
> > |
16 |
> > just by allowing a check on emerge to verify your local keyring is still |
17 |
> > fresh etc. this doesn't require a new tree, and would work for ppl that are |
18 |
> > periodically online etc. Keyring maintenance would have to be a tool |
19 |
> > outside of portage altogether tho. |
20 |
> |
21 |
> Yup but you can't invalidate a key on the keyserver in the case of a rogue |
22 |
> developer. If you're online, why not update the portage tree, get all the new |
23 |
> security updates etc. and the ACLs in one go? Putting the allowed keys and |
24 |
> access lists into the portage tree makes the most sense to me. Otherwise |
25 |
> you're going to have to synchronise them anyway! |
26 |
> |
27 |
|
28 |
if an attacker can mod the acl list of keys he can add his and his buildts etc. |
29 |
you need external verification outside of just the mirror your syncing on. |
30 |
|
31 |
> |
32 |
> -- |
33 |
> gentoo-dev@g.o mailing list |
34 |
> |
35 |
> |
36 |
|
37 |
-- |
38 |
gentoo-dev@g.o mailing list |