Peter Simons wrote:

> So why is the Gentoo team so incredibly reluctant to do
> anything about it?

I don't like your style, but I think I can get your point. The current
system update setup is vulnerable to man in the middle attacks between
the master rsync server and the end user. And you think there is an easy
solution that can be set up really quickly that will mitigate that risk.
So you're not happy because you don't get why we don't already include
your solution.

First, please note that hose attacks are not that easy to perform and
that you probably have a lot to worry about if you have someone
malicious controlling all network flow and DNS information to your
machines. Saying this doesn't mean I am ignoring the risk you talk
about. I'm just putting it in perspective.

Second, "the Gentoo team" is not one person sitting in the dark and
saying "No, you're wrong, period.". It's a large group of volunteers,
and you'll find some of them (mostly security guys) have been battling
for years to get a good and secure update mechanism in Gentoo. For some
of them, security is highest prio, for others it's stability, for others
it's performance, etc. That's why things are going on slowly. And
frankly, we're way better now than we were a year ago.

Now on to your solution. As the funny guy with the beard says, security
is a trade-off, it's not a binary status. We are not "unsecure" now and
we'll not be "secure" with your solution applied. The risk here is that
someone controlling your network flow and/or poisoning Gentoo DNS
information can execute code with root privileges on any machine doing
sync and updates. Your solution mitigates that risk by securing the link
between the master rsync server and the end user using a signed digest
that is controlled at the end user level using a key downloaded by other
supposedly secure means, and kept updated by other supposedly secure
mechanism.

This does not mitigate the (supposed lower) risk of having the main
rsync mirror compromised, the Gentoo CVS tree poisoned by unauthorized
users, or getting a corrupted master public key from your
man-in-the-middle controlling-all-network-flow bad guy.

This is not the ultimate solution but one which has the merit of being
simple (from your point of view) to be set up and that secures a part of
the chain that you feel is the easiest to corrupt. So it's a band-aid,
waiting for something more serious (all tree file signing with
individual dev keys) to get ready. We'll let the concern of whether
applying such a solution will or will not slow down the set up of the
real one true good but too-slowly-coming security mechanism to others.

What are the trade-offs you forget because of your agenda ? I can think
of two, and being a security-oriented person, I suppose others with a
different agenda will find more.

First, this added security layer will mean that for all users (including
those who don't care) the speed of availability of software through
portage will be a bit lower. We'll have to sync rsync with CVS,
calculate the digest and sign it before having it replicated with the
second-order mirrors. How much time does it take to generate MD5 (+
probably SHA1 I suppose) of every file in portage ? I would like to
know. Some users might complain that the added security they don't care
about because they don't think MiM attacks likely on their systems will
slow software availability. Who cares it takes an extra 30 minutes ?
Tell that to those who sync 4 times per hour.

OK, next, the end user side. You'll have to hook up tree signature
verification to portage directly, as portage somehow executes code it
fetched from the network when updating metadata and performing profile
updates. We have a very large bunch of users (obviously not on this
mailing list) complaining that emerge sync is waaaay too slow. How much
time does it take to do MD5+SHA1 verification of every single file in
/usr/portage after the rsync is complete ? That also I would like to
know. That would help evaluate the real tradeoffs your solution implies.
An optional FEATURE ? Letting the no-clue users out of protection is not
nice, but I suppose it's needed by your solution.

Last, your simple solution means work for the infrastructure team (to
change the rsync replication process, provide for CPU time to perform
the digest etc... And the portage team (testing and releasing extra
functionality controlled by a FEATURE most people won't activate because
 it slows down the emerge sync process). Rephrasing your proposal as :

(1) infrastructure scripts to generate signed digest
(2) portage patches including the FEATURE of glocal verification
(3) hard data showing the performance hit server-side and client-side

would certainly help us. It's not your job to do an implementation
proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a
community distribution. The "Gentoo team" cannot do everything, it needs
user support. And yes, even posting a small script helps.

-- 
Thierry Carrez
Operational Manager, Gentoo Linux Security