Re: [gentoo-dev] Redux: 2004.1 will not include a secure portage.

[Koon]

Chris Bainbridge wrote:
>>So for for me the only objective is :
>>* protect against compromised rsync server
>
> Why? There are more gentoo developers than rsync servers. Their machines do
> more than rsync servers. What reason is there to believe that a compromise of
> an rsync server is more likely than compromise of a developer machine?

To "compromise a dev box" is in fact to compromise the dev signing key. 
That means having access to the key (which could/should easily be stored 
on removable media) and access to the passphrase. So you need full root 
compromise (or physical) access *and* wait for the dev to enter his 
passphrase.

On the other hand, to compromise a rsync server just needs user level 
access to the repositories. The exploited machine is directly usable, no 
incubation time. Furthermore, you don't even need to compromise the 
rsync server. Just set up one and have it included in the rsync 
rotation. Then just wait for your trojans to call home.

Hack Gentoo boxen howto :
http://www.gentoo.org/doc/en/rsync.xml

Brandon Hale wrote:
> We will be moving at some point to Gentoo-only rsync mirrors in the main
> round robin DNS. Servers controlled by Gentoo have a high standard for
> security, and are admined by our ever watchful infra team. See

That would take care of the easy exploit above. But I still think the 
best is to quickly get the rsync mirror security out of the equation.

I think there is a consensus on managers to concentrate on the quickest 
solution that would meet the single objective of not relying on all 
rsync mirrors security. 2004.1 seems an unrealistic target, do you think 
2004.2 should be the target ?

Then you should start a specific thread to compare implementations, with 
the single goal of solving the rsync security problem. Every person with 
a detailed solution should post there, and once it's done, we can 
compare how easy (and fast) it is to setup. Use Occam's razor to select 
the best (the easiest), and if the best also solves other security 
problems (compromised dev or rogue dev or whatever), then all the 
better. But I don't think so, and like rac said, I don't want perfect to 
get in the way of better. The winner writes a GLEP. Koon's happy ;)

We already have one detailed post, Robbat2's implementation :
http://marc.theaimsgroup.com/?l=gentoo-dev&m=108017986400698&w=2

pauldv : you probably should summarize your fast-rotation signing key 
implementation in a new post for the record.

Once you get decided on the implementation, I can help writing docs if 
the winner developer doesn't have too much time to spend on this problem.

-K

--
gentoo-dev@g.o mailing list