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