Security release criterion proposal

[Adam Jackson]

On 5/18/11 11:57 AM, 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

Seems reasonable at first glance.

One anecdotal experience: FC5 (wow) shipped with an X server that was 
vulnerable to a local root exploit: due to a bug, normal users could set 
the X server's module path, and the server would always load a certain 
module first, so you could just set an ELF constructor that called 
exec("/bin/sh") and win.  The public commit to fix the issue was 20 
March 2006, the exact day of the FC5 release, so I suspect we chose the 
embargo date on that basis.

Which, I think, was the right move.

The concern I would have with an explicit policy like this is the 
schedule effects.  We would not be able to commit or build a package 
with the embargoed fix until after the embargo date.  _Then_ we compose. 
  Then we test (unless we think existing testing is sufficient).  Then 
we push to mirrors.  Then we make the release links public.  That whole 
process is still on the order of a week I think, which is slightly 
longer than one would desire.

- ajax