Bad Maintainance! [LWN.net]

Bad Maintainance!

Posted Dec 2, 2003 22:14 UTC (Tue) by LogicG8 (guest, #11076)
In reply to: Bad Maintainance! by AnswerGuy
Parent article: The brk() vulnerability

I disagree, I think Marcelo is doing the right thing.
It represents a fundamental shift in the way the
kernel is maintained, but I think it's for the best.
What this does is shift responsibility from the
vanilla source tree to individual distributions. All
the mainstream distros have their own kernel trees.
They should keep on top of security fixes and
immediately bump out a new release when something
happens. The vanilla sources aren't for everybody
anymore. I'm not trying to be elitist here, most
people just don't recompile their kernel. If you are
smart enough to compile your own kernel you are
probably smart enough to patch it when a fix comes
out. If not you might want to consider letting a
proffessional do it for you and use the kernel that
comes with your distro.

Stable releases should be for milestones in development
not for every security bug that comes out. Distributions
should provide security updates. To do otherwise dilutes
version numbers and makes them useless for indicators of
progress.

(Log in to post comments)

Bad Maintainance!

Posted Dec 3, 2003 0:26 UTC (Wed) by dlang (subscriber, #313) [Link]

you see it as a good thing to discourage people from useing the vanilla tree and instead have everyone use a tree patched with some arbatrary set of patches? (last I heard Suse and Redhat both have >200 patches in their trees)

if every distro does this how in the world can anyone track down a bug report?

I agree that the way the 2.4 kernel releases have been done tends to encourage this, but I see this as a bad thing as it further fragments the testing base.

If a security hole is found and itentified as such (which I agree this was not) then the proper procedure is to apply the fix to the last released kernel, release a new kernel, and then take all the work that was done in the meantime and apply it to this new kernel and pick up where you left off (you can even keep the same preX number if you want) the use of source control systems makes this fairly trivial to do.

counting on people to be paying enough attention to every patch that is released to know that it's a security patch and then apply it themselves (or wait for a distro to do so) becouse you have a fixed 'release procedure' is being lazy

Bad Maintainance!

Posted Dec 4, 2003 5:22 UTC (Thu) by iabervon (subscriber, #722) [Link]

For vanilla kernels, I think the best idea is really a patch that applies
to all of the affected versions. Releasing 2.4.23 with that as the only
change is fine for x86 users with standard hardware, but if you're
running on a SA-1110 with a CS integrated NIC that requires a patch that
applies cleanly only to 2.4.8, a patched kernel which is very similar to
2.4.2x isn't going to be very useful. Furthermore, this sort of security
fix is generally only a line or two in a part of the kernel that doesn't
change very much.

What I think should happen in this situation is really that Marcelo
should bless a particular patch as the correct fix for the problem for
each 2.4 release, and kernel.org should distribute it, and it should get
into the next release. Fixing this sort of security problem should really
be orthogonal to the regular kernel development process.