Adam Jackson wrote:
> 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.
The thing is, if we block the release for each and every known security
issue, considering the time passing between notification and public
availability of a fix, we will never be able to release anything. We have to
draw the line somewhere, and the best way to do it is to use our time-based
schedule.
We have done 15 releases successfully that way, what's the reason for
changing this approach now? And how can this not lead to a chain of slippage
where each slippage for a security fix causes several new security fixes to
pop up, for which we slip again, ad infinitum?
We cannot fix all security issues any more that we can fix all bugs. We have
to get SOMETHING out at some point.
> 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.
You don't KNOW that it will get the user rooted. Now if the hole is in a
service listening to the Internet by default and is getting exploited by an
automated worm, you can reasonably say that it WILL get the user rooted, but
if it's e.g. a browser vulnerability, it will only hit the users if and when
they access an infected or malicious site. Hopefully they'll have installed
our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org
will not carry some trojan horse!)
And your logic is flawed in that you assume that every user installs Fedora
the day of the release. That's actually very far from the truth. All your
efforts to release without known security vulnerabilities are for naught
when the next one inevitably comes up soon after the release and there won't
be a fixed set of live images for 6 months.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
