| 1 |
On Sun, Aug 08, 2004 at 11:34:16PM -0700 or thereabouts, Greg KH wrote: |
| 2 |
> So what would happen for security fixes? Rely on the latest release |
| 3 |
> from upstream to be used instead? |
| 4 |
|
| 5 |
Yes, in most cases. |
| 6 |
|
| 7 |
> This can cause real problems, as a lot of SATA users just found out with |
| 8 |
> the most recent Fedora kernel update due to the security fix. They went |
| 9 |
> with the most recent kernel, which happened to rename their disk drives. |
| 10 |
|
| 11 |
Yes, but backporting security fixes to code that the original author never |
| 12 |
planned to have it used with causes its own set of problems. |
| 13 |
|
| 14 |
> What is the downside of just backporting the security fixes to the |
| 15 |
> versions marked "stable" (becides developer time)? |
| 16 |
|
| 17 |
Don't discount "developer time" as inconsequential. We already have issues |
| 18 |
with things getting patched in a timely fashion. Trying to backport (and |
| 19 |
test!) everything will only make it worse. |
| 20 |
|
| 21 |
Another gentoo-specific reason is the fact that, right now, our QA is |
| 22 |
inadequate to support backporting. We're setting ourselves up for failure |
| 23 |
if we set a policy of backporting all security fixes without having |
| 24 |
adequate QA in place to make sure they work properly. (and no, GLEP 19 |
| 25 |
isn't designed to deal with QA -- that's a whole separate GLEP entirely) |
| 26 |
|
| 27 |
In general, the GLEP suggests not backporting. If there are extenuating |
| 28 |
circumstances, then the package maintainer is free to backport at their |
| 29 |
discretion. A good example of this would be a security fix that is only |
| 30 |
released in a major revision of the package. (MySQL 5.0, for instance) In |
| 31 |
that case, it might make sense to backport the fix to MySQL 4.x. |
| 32 |
|
| 33 |
--kurt |
Archives