Drawing lessons from fatal SELinux bug #1054350
kevin.kofler at chello.at
Sat Jan 25 16:56:33 UTC 2014
Adam Williamson wrote:
> On Fri, 2014-01-24 at 13:36 +0100, Kevin Kofler wrote:
>> * If the package is already so screwed that it breaks the whole system,
>> it cannot realistically get any worse.
> Sure it can. It can wipe all your data, or mail it to the NSA...
That's why I said "realistically". What is the probability of something like
that happening IN PRACTICE from a trivial change, especially one that
reverts something to a known previous state? Perfect QA does not exist
anyway, so it is all a matter of probabilities.
> "Breaks the whole system" is high on the Pantscon Scale, sure, but it's
> not the highest. Data loss and security compromise both come higher.
And you seriously think a week (or 2) of testing can catch that? Security
vulnerabilities can take years to get noticed, creeping data loss days to
weeks. The only thing in your catastrophe scale that can be noticed in 1-2
weeks is blatant "wipes entire directories immediately" data loss, something
extremely unlikely to happen from a regression fix (but so are the other
catastrophic scenarios, unless the problem was already there before the
regression fix and is thus no reason to withhold the fix).
>> * A regression fix is usually a trivial change, often reverting something
>> to a previous, already well-tested, state.
> Sure. And what could possibly go wrong.
The risk of a catastrophe as you described happening needs to be estimated
(a tiny fraction of a percent) and weighed against the breakage (and denial
of service, if security terms are the only ones you understand!) of keeping
the broken update in stable for longer (and thus also letting it affect more
users). I think it is blatantly obvious that the first theoretical risk is
the much better one to take compared to the second, very practical one.
More information about the devel