Re: [gentoo-dev] GLEP 19, reloaded (again)

[Kurt Lieber <klieber@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Sun, Aug 08, 2004 at 11:34:16PM -0700 or thereabouts, Greg KH wrote:
> So what would happen for security fixes?  Rely on the latest release
> from upstream to be used instead?  

Yes, in most cases.

> This can cause real problems, as a lot of SATA users just found out with
> the most recent Fedora kernel update due to the security fix.  They went
> with the most recent kernel, which happened to rename their disk drives.

Yes, but backporting security fixes to code that the original author never
planned to have it used with causes its own set of problems. 

> What is the downside of just backporting the security fixes to the
> versions marked "stable" (becides developer time)?  

Don't discount "developer time" as inconsequential.  We already have issues
with things getting patched in a timely fashion.  Trying to backport (and
test!) everything will only make it worse.  

Another gentoo-specific reason is the fact that, right now, our QA is
inadequate to support backporting.  We're setting ourselves up for failure
if we set a policy of backporting all security fixes without having
adequate QA in place to make sure they work properly.  (and no, GLEP 19
isn't designed to deal with QA -- that's a whole separate GLEP entirely)

In general, the GLEP suggests not backporting.  If there are extenuating
circumstances, then the package maintainer is free to backport at their
discretion.  A good example of this would be a security fix that is only
released in a major revision of the package.  (MySQL 5.0, for instance)  In
that case, it might make sense to backport the fix to MySQL 4.x.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]