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 |