Kernel releases for security updates

Kernel releases for security updates

[Gregory Boyce]

Folks,

Lately on this list I have been hearing a lot of discussion about putting 
out point releases for security and bug fixes to the stable series of 
kernels.  There has even been a single release (2.6.8.1) that actually 
followed through with this.

What has not been clear to me from the threads is how far back people are 
planning on supporting with these point releases?  A lot of people seem to 
be very interested in being able to run a kernel for extended lengths of 
time, but most of the discussion on point releases has been about getting 
a 2.6.X.1 while 2.6.X+1 is still in it's pre stages.  What about the 
people running 2.6.X-1?  Can they expect to get a point release for 
security updates?

I've been thinking about this, and it seems to me that there is going to 
have to be a choice between either supporting just the current stable 
release, or supporting the last X releases.  The first option is going to 
leave a lot of people unhappy as major changes get put into releases, and 
the other option is going to be painful to support.

Rather than actually putting out point releases for the previously 
released kernels, why not just create a centralized repository for the 
security patches?  In a lot of cases security patches can be applied as is 
to a number of different kernel revisions.  For the ones that cannot, 
variances of the patches could be posted along with it clearly marked as 
to which patches apply to which kernels.

Thoughts?

--
Greg Boyce

Re: Kernel releases for security updates

[Alan Cox]

On Mer, 2005-01-12 at 19:45, Gregory Boyce wrote:
> be very interested in being able to run a kernel for extended lengths of 
> time, but most of the discussion on point releases has been about getting 
> a 2.6.X.1 while 2.6.X+1 is still in it's pre stages.  What about the 
> people running 2.6.X-1?  Can they expect to get a point release for 
> security updates?

For -ac I'll support just the current release unless there are real
stability problems or a hole occurs just as Linus puts out a new release
and there isn't enough test data to see what needs fixing in it in which
case I'll fix both.

Alan

Re: Kernel releases for security updates

[Frank Steiner]

Gregory Boyce wrote

> Rather than actually putting out point releases for the previously 
> released kernels, why not just create a centralized repository for the 
> security patches?  In a lot of cases security patches can be applied as is 
> to a number of different kernel revisions.  For the ones that cannot, 
> variances of the patches could be posted along with it clearly marked as 
> to which patches apply to which kernels.
> 
> Thoughts?

I guess the new -as tree is more or less achieving what you want. If
Andres gets enough support from other people, it might be possible to
maintain even more than one or two former releases...

[x] Voting for the -as tree to become an official tree on kernel.org :-)

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: Kernel releases for security updates

[Alan Cox]

On Gwe, 2005-01-14 at 08:01, Frank Steiner wrote:
> I guess the new -as tree is more or less achieving what you want. If
> Andres gets enough support from other people, it might be possible to
> maintain even more than one or two former releases...

The problem is deciding what goes into such a tree. Do you go security
fixes only which nobody afaik is doing now, do you mix them with key
fixes and if so how far do you add fixes - thats a real PITA because you
can get odd clear fixes for minor problems (eg NFS df) that have never
been tested hard standalone. You can also get dependancies on
non-security fixes for security - -ac for example included my IDE work
to deal with the various IDE exploits/races. Though only minor security
wise there isn't a trivial fix for these with the broken locking in
Linus IDE and its going to take time for Bartlomiej to be happy with my
locking changes.


Alan