| 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 |
Archives