Gentoo Archives: gentoo-security

From: Jeremy Bowers <jerf@××××.org>
To: gentoo-security@l.g.o, gentoo-core@l.g.o
Subject: Re: [gentoo-security] Security concerns and portage versioning
Date: Wed, 18 Feb 2004 17:18:32
Message-Id: 40339E91.7020407@jerf.org
In Reply to: Re: [gentoo-security] Security concerns and portage versioning by Calum
1 Calum wrote:
2 > The more choice the better, IMHO.
3
4 Not true. You already *have* maximal choice; assuming you want to mimize
5 emerges, you are required to pick and choose exactly which updates you
6 want to emerge, by hand, with no automation support.
7
8 If you're not going to reduce this choice to some degree by providing
9 some bundling, then there's no point continuing; we already have the
10 system that provides maximal flexibility.
11
12 Some of us would like to be able to "volunteer" for portage to have a
13 little less flexibility and automatically do the minimal security
14 updates, even though that technically reduces our choices (by making
15 some things harder since they go "against the grain"). Endless (and
16 ultimately futile) categorization of the security issue types reduces
17 the value of "emerge security" by requiring the user to make almost as
18 many choices about what they care about as the original state we are in now.
19
20 Calum, I'm sure I'm not going to convince you of this, but I think it
21 should be said in general: I don't see any reason to force the admin to
22 choose between *which* security fixes need to be applied. What
23 security-concious admin is honestly going to update only *remote-root*
24 and leave *local-root* alone, when a "local-root" exploit + a
25 (potentially unknown) remote shell exploit (or potentially even weaker
26 exploits) constitutes a remote-root exploit?
27
28 The -sX solution seems like a good idea to me. No real need to
29 differentiate between the reasons, IMHO.
30
31 --
32 gentoo-security@g.o mailing list