Drawing lessons from fatal SELinux bug #1054350

[Kevin Kofler]

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.

        Kevin Kofler