Dan Margolis writes:

 > [the Gentoo security process is] designed solely to
 > promote the absolute best security we can offer, never to
 > save face or gain marketshare.

Good. I have a proposal how to the security of the
distribution could be enhanced by a bit. I have posted it 4
times by now. It would be way cool if the proposal would
find entry into the Gentoo security process so that a rather
fundamental problem in the distribution process can be
fixed. If there is a better way of doing things than what I
have suggested, then I am all ears. Doing nothing, however,
is not an answer I am prepared to accept and as of now I
have no indication that this problem is being solved or even
taken seriously.


 > And of course, if a user wants to see it fixed, that user
 > can always submit a patch.

I cannot submit any patch. There is no "patch". There is a
3-line shell script which someone who has administrator
privileges on the main server can put into the crontab, and
there is some GPG key which someone with administrator
privileges on the main server has to create. I can do
neither of that.


 > But I'm not clear on what *your* goal is here by making a
 > public stink.

My goal is to remedy a vulnerability in the Portage system
that has not been addressed for the last 1.5 years even
though it was known.


 > I have to wonder, for the amount of time you're spending
 > on this, couldn't you just write the patch yourself at
 > some point and save a lot of trouble?

Add the key

  ssh-dss AAAAB3NzaC1kc3MAAACBANHjGfHMVluJJEabXHuVvsmbbXu9hcC3G0KCU4RNGNR14tnv4FeDWIUZumrXfQ0V13D1zbOyw3IyEHTYVP7E1TNw+uEb7CjyGJY2TEyEROlDJ37mh5h8LVOrZbVZY/xHsNBgDiZccGKPkOwLcEzLiFJuDhMiQF67/Mzm69FVmCT9AAAAFQDpFMaASINIbv2ugG8R500QKz5ipwAAAIAZFWUJ5oU0p0zinH8Dk7V8SRXGtRr4LSWbncP1sza7AtQ+3RjtFfnPihAcjDJjzYw2rPeu+M140l3okB3A5P399XEW6pPuXW9wJVJLxJG4vZpsqHYrX6OX6kOjBBqU5RvPnWvXpKlUsYdJ3ZllDq5rmH0u26BBe7htsrhQzJPP/gAAAIEAmeN415RrRv95EVxFqpGIa7KqhIjktlLYVyy+8pFHoE1DV7MCaresaRAXTzHPpzHhU8mQ19MDObDZIhWnA9y5Qqk4UIUl7/8vF76FuCPEdsRZk5NX8GlIJAo0ghxKxdAJfHC+YGRSHL/l7eLS5WH//5vuw6egAl40UuwpEyF4O50= simons@...

to ~root/.ssh/authorized_keys on the appropriate machine,
let me know how to log in, and I'll do it. I am serious.


 > So if it seems we're unresponsive, or unhelpful, or don't
 > fix everything you'd like, just try sometimes to be a
 > little more understanding.

I would be a lot more understanding if this weren't about
the machines of completely clueless people who use the
system and have no idea at all what kind of risk they take
every time they update their portage tree. If nobody has the
time to fix this soon, then post a public security advisory,
and I'll back off immediately.


Thierry Carrez writes:

 > [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.

Could we please STOP speculating about my feelings,
motivations, or deficits as an individual and address the
problem?


 > [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.

I think it would be better to let the users -- who's
machines are at stake here -- decide whether they feel this
is a risk worth taking. Make the flaw public and explain
what it means, and we'll see what the community thinks about
the feasibility of man-in-the-middle attacks.


 > 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 [...]

I understand the risk, I know what it means, I know how it
can be exploited, and I don't need it explained to me.
However, there are several thousand users out there on the
Internet who may not know about it.


 > [Your solution] 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.

Duh, of course it does not. What is your point? It doesn't
solve every problem we have, so better not do it at all?


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

Make a separate mirror then, which has signed and
authenticated contents that is updated only once a day, once
a week, whatever. Then those who care can use the secure
system with slower package availability and those who don't
care can stick with the insecure but fast version. Right now
there is no way to choose.


 > How much time does it take to generate MD5 (+ probably
 > SHA1 I suppose) of every file in portage ?

On my system it took a bit over 4 minutes. I have no idea
how fast your machines is. But we'll never find out unless
we try it.


 > How much time does it take to do MD5+SHA1 verification of
 > every single file in /usr/portage after the rsync is
 > complete ?

I'd guess about as long as it takes to generate them. Those
you don't care can disable it.


 > An optional FEATURE ? Letting the no-clue users out of
 > protection is not nice, but I suppose it's needed by your
 > solution.

The unfortunate truth is that you cannot protect users who
don't have a clue (because they don't verify the GPG key to
begin with), so I don't have a problem with making this
functionality optional.


 > Last, your simple solution means work for the
 > infrastructure team [...]

_Any_ solution will mean work for the someone. No solution
will mean a LOT more work once it turns out a couple of
systems have been compromised, because then you'll have
hundreds and hundreds of people like me flooding your
mailing lists with questions and complaints.


 > It's not your job to do an implementation proposal ?
 > That's the "Gentoo team" job ? Man, get real. Gentoo is a
 > community distribution.

I keep hearing that over and over again, yet "Gentoo" seems
to be awfully unwilling to pay attention to the community
when it tries to help. Just so that we don't forget the
facts: One and a half years, guys. I have posted ... I dunno
... maybe 30 messages to this list by now? How much progress
have we made so far?

Let's get to work. Tell me what problem there is with my
proposal and I'll see whether I have ideas how to improve
it. Tell me a proposal of your own and I'll try to help
finding flaws in it. Give an account on the machine in
question and I'll to implement it.

Get this problem fixed or make it public and there is no
need for me to be "public stink".

Peter


--
gentoo-security@g.o mailing list