> It's not as simple. Security means everything and nothing at the same
Willy, please do read the previous discussion before commenting. the problem isn't that people
are unable to determine whether a given bug has a security impact or not. that is a separate
issue and is not the point raised now. the problem we exposed is that of covering up security
impact information when it *is* already known to the kernel developers. you're privy to that
information yourself and in silent agreement with that policy, don't pretend you don't know
(care to explain to the rest of the world that itanium hardware bug still unfixed after 2
> There are people who consider security only about risk of intrusion.
> Other people consider the risk of remote or local DoS. Others the risk
> of data leak. If we want to be picky, everything which can permit a
> non-privileged user to cause a malfunction resulting in a degradation of
> performance, integrity, availability, confidentiality or traceability is
> a security issue.
and where's the problem? you simply include the relevant info in the commit and let the users
decide which ones they're interested in. the current problem is that by omitting or
obfuscating any such info makes it *impossible* to quickly select the interesting commits.
you're not improving linux security by making it hard for users to make decisions.
> Overall, I think the security issues are correctly taken by the middle
> chain (2.4 and 2.6-stable),
once again, to stress the point: no, they are *not* correctly handled. ask Chris Wright about
> but the fact that information sometimes gets lost at the starting point
> makes it difficult to dig for the whole thing.
it doesn't get 'lost', it gets intentionally omitted. and it's not sometimes but pretty much
every time now. case in point,
knowing Ilja's past work, i can't imagine he didn't report this as a bug with security impact
(not that it's hard to figure out even if he didn't) yet there's no mention of it in the
commit, not to mention a backport to -stable.