Security release criterion proposal

Adam Jackson ajax at redhat.com
Wed May 18 18:02:58 UTC 2011


On 5/18/11 1:44 PM, Adam Williamson wrote:
> On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
>> On 5/18/11 1:22 PM, Kevin Kofler wrote:
>>> Adam Williamson wrote:
>>>> # There must be no known remote code execution vulnerability which could
>>>> be exploited during installation or during use of a live image shipped
>>>> with the release
>>>
>>> This is just completely and utterly moot considering that there are going to
>>> be many more unknown vulnerabilities than known ones, and that several of
>>> those are inevitably going to come up during the 6-month lifetime of a
>>> release.
>>
>> The difference between a known and an unknown security bug is that, if
>> _you_ know about it, it's virtually certain that someone malicious
>> already does too.
>>
>> We can't avoid unknown risk exposure.  You're arguing for ignoring known
>> risk exposure entirely.  Seems a touch irresponsible.
>>
>> Also: twelve month.
>
> Well, I think his point is that it's almost certain that some 'unknown'
> exposures will become 'known' during the life cycle of a release, at
> which point the live images we release three months previously are
> vulnerable to a known security exploit and there's exactly nothing we
> can do about it - so worrying about the ones we _can_ fix at release
> time becomes less important, when viewed from that perspective. It's a
> good point.

It's a rationally argued position, but argued from an initial state that 
does not reflect reality.

I mean, the conclusion from that line of reasoning is that all releases 
are futile: any sufficiently severe bug unknown at release time could be 
discovered later, and could be so crippling as to make the release useless.

I don't necessarily disagree with that logic either.  However, we've 
decided to do releases.  Therefore we ought to have some standard of 
quality for release content definition.  After that it's all a matter of 
drawing the line.  I'd argue that knowingly exposing the user to a 
remote root exploit is actively negligent behaviour; remote user code 
execution, less so but still very bad; local privilege escalation, less 
so still.

I'd rather not ship something that I _know_ will result in the user 
getting rooted.  This is so fundamental a tenet of quality that I have 
difficulty even believing someone could disagree.  I guess Kevin's brain 
is simply something I should stop being surprised by.

- ajax


More information about the devel mailing list