Re: [gentoo-security] Re: Out of air

[Chris Haumesser]

Sorry for the html. Here's a more legible version of my last post:

>Why not just take out those points in between?
>
>GENTOO_MIRRORS="http://gentoo.osuosl.org" emerge-webrsync
>
>

Huh? How does this protect me from a potential MITM attack at my ISP, or
on my neighbor's insecure wireless network, which my laptop is currently
attached to? A simple traceroute shows sixteen hops between me and
gentoo.osuosl.org. That's sixteen potential opportunities for nastiness.

How can I even be sure that I am connecting to gentoo.osuosl.org, when
rsync is completely anonymous, with no ssl, no certificate chain,
nothing to verify the server's identity other than its rsync banner???

I might care less about about verifying the integrity of my portage
tree, if I could at least be more certain of what server I'm connecting
to! Having neither assurance is a bit unsettling on a production machine.

>The portage
>team would need to implement support for verifying the signature is valid.
>
No, they /need/ not, and should not. I would be _thrilled_ to just get a
signature with my tree, that I can manually verify by firing up gpg. No
portage support is necessary for this interim solution. We all know
something better is in the works for portage.

Work on portage should absolutely focus on the better, long-term,
previously agreed-upon solution.

If the devs can just sign the tree, I can verify that my portage is what
the devs intended me to have, and the devs can continue working on the
more polished approach. Work on the best solution moves forward, while
those of us with heightened security needs (today!) can be more
confident of the integrity of our portage trees.

>The infrastructure team would have to do some careful planning and possibly
>restructing of job control on the master rsync and cvs servers.
>
While there is surely some work in the area of job control, it has been
pointed out already that the proposed solution is not terribly resource
intensive. So unless gentoo's infrastructure is already severely
stretched to the max (is it? how do i know?), I can't see how this is a
huge obstacle. Is there an admin who can weigh in with an informed
answer on this? Too much speculation on this point, not enough fact.

>Following this would be plan of action for the case
>that the all-powerful key is compromised.
>
Key management/security/policy is an issue that will need to be
addressed regardless of the mechanics of any signing process, so I don't
see how that is a blocker to this proposal. The idea of a master key is
equally applicable (and optional) to both the proposal on this list, and
the one currently under development.

> Then there is also the up to six
>month transition period between this solution and the solution that is
>currently being implemented.
>
If portage support for this temporary hack is not implemented, there is
clearly no six month transition period. Just that one day, those of us
who have been manually verifying the signature will no longer need to do so.


I must be misunderstanding something, because I still fail to see what
is so terribly difficult or impractical about merely generating a
signature file. Hell, this could already be done and implemented in the
time we've all wasted on this stupid thread.

No one is trying to derail or criticize or block the current
implementation. We just want some basic assurances (now, today) that the
scripts we're downloading are legitimately from the gentoo devs, who we
trust. As it stands, we can verify neither the identity of the rsync
server, nor the integrity of the portage tree we're downloading. That is
indeed a problem. And it's one we can mitigate now, even if the best
solution is still a ways off.


Cheers,


-C-