On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote:
> Hey, all. The topic of whether and which security issues should block
> releases has come up several times before. While we haven't actually had
> many really serious security issues to worry about since the
> introduction of the current release criteria system, I think it's
> certainly something we should take into account. At the same time, it's
> fairly established in practice that we don't just consider anything
> worth issuing a CVE for as a release-blocking bug. So, to capture what I
> believe would be the intent of the project, I propose this as an Alpha
> release criterion for F16 onwards. (For those on devel and security
> lists who may not be completely familiar with the release criteria /
> blocker system, this would mean that any bug for an issue which breached
> the criterion should be considered a release blocker for any Alpha, Beta
> or Final release).
>
> # 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
I mostly agree with this criterion with one exception below.
> Points to consider:
>
> * Possible variants to the type of vulnerability covered...do we also
> want to make local privesc vulns blocking? Conversely, do we want to
> make only remote *root* execution vulns blocking? I don't know if anyone
> would want to go as far as making DoS vulns release blocking, but speak
> up if you would! (Of course there is again the local/remote distinction
> to consider there: 'all DoS vulns' would be a much tighter standard than
> 'remote DoS vulns').
>
> * The caveat about where the issue is exploitable is important because
> if you can't exploit it from the installer or a live image, it becomes
> less relevant whether we ship with it or not, because you would be safe
> with the first post-install update assuming we submitted an update for
> the issue promptly. But it may be the case that we want to broaden it
> out to also cover issues that can be exploited from a default DVD
> install, if we consider the window between install and first update (if
> updates repos aren't used during installation) to be unacceptable.
I would vote for this slight broadening - that is to make also remotely
exploitable issue in the default DVD install a release blocker.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
