Security release criterion proposal
ajax at redhat.com
Wed May 18 17:15:07 UTC 2011
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.
More information about the devel