From: Adrian Bunk <bunk@stusta.de>
To: Rob Landley <rob@landley.net>
Cc: "Mukund JB." <mukundjb@esntechnologies.co.in>,
linux-kernel@vger.kernel.org
Subject: Re: Which version of 2.6.11 is most stable
Date: Sat, 12 Nov 2005 05:32:19 +0100 [thread overview]
Message-ID: <20051112043219.GV5376@stusta.de> (raw)
In-Reply-To: <200511112149.08324.rob@landley.net>
On Fri, Nov 11, 2005 at 09:49:08PM -0600, Rob Landley wrote:
>
> One question I've wondered about for a bit...
>
> The diff between each dot release (ala 2.6.12.0->2.6.12.1) can theoretically
> be backported to an older kernel. So in theory, at least some of the new
> security fixes can be applied to older kernels. (Yeah, this necessarily
> complete. Whether or not the patch makes any sense at all in the older
> context, and whether or not that's everything they need to do... That's a
> seperate issue. It allows some minimal, relatively straightforward
> maintenance to be done on systems that are stuck with older kernels by
> management fiat.
>
> The gap is the jump to the next major release. Suppose that 2.6.15 makes it
> up to 2.6.15.10, and then 2.6.16 comes out. Are there any security fixes in
> 2.6.16 that weren't in 2.6.15.10? Fixes which would have been in a 2.6.15.11
> if the next big release had been delayed another two weeks?
>
> From a practical standpoint, somebody stuck on 2.6.15 for another six months
> is likely to at least try to apply the next security update (the diff between
> 2.6.16->2.6.16.1) to their old kernel, but are they missing a week or two's
> worth of security fixes?
They miss a completely undefined amount of fixes.
Consider e.g. the case that 2.6.16 contains fixes that are later
identified as possible security issues.
The 2.6.16->2.6.16.1 patch fixes bugs in 2.6.16 - trying to apply it to
a 2.6.15 kernel might both leave security holes and add new breakages.
> I'm trying to clarify what my question is: When a new stable kernel comes
> out, do the dot-release guys do one more release of security-only fixes to
> patch all the known vulnerabilities that the new one addressed before moving
> on? Or do they just leave a gap and say "upgrade"?
There is no last dot-release - and it wouldn't help.
If you are running ftp.kernel.org kernels you have to upgrade to the
latest one or you will definitely miss security fixes.
If this is a problem for you stay with distribution kernels -
distributions offer exactly the service of security fixes for their
kernels for a well-defined amount of time.
> Rob
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2005-11-12 4:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-07 10:08 Which version of 2.6.11 is most stable Mukund JB.
2005-11-07 11:51 ` Adrian Bunk
2005-11-12 3:49 ` Rob Landley
2005-11-12 4:32 ` Adrian Bunk [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-11-07 10:09 Mukund JB.
2005-11-08 15:43 ` linuxdevelop linux
2005-11-07 13:08 Mukund JB.
2005-11-07 13:37 ` Paolo Ciarrocchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051112043219.GV5376@stusta.de \
--to=bunk@stusta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mukundjb@esntechnologies.co.in \
--cc=rob@landley.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.