Bad Maintainance! [LWN.net]

Bad Maintainance!

Posted Dec 2, 2003 19:34 UTC (Tue) by AnswerGuy (subscriber, #1256)
Parent article: The brk() vulnerability

I'm increasingly unhappy with Marcelo's maintenance of the 2.4 kernels.

He has to learn that fixes that impact security in the core kernel must be released as a new kernel IMMEDIATELY! Pussy footing around with 5 or 6 pre-releases that contain lots of lesser fixes is a dis-service to the entire community. There are times to release a new stable kernel with a single bug fix, even it that's ONLY A SINGLE LINE.

I seem to recall there was a similar problem around 2.4.19 or 2.4.20 --- a known fix for a vulnerability was deferred in favor of the release based on the rc* series --- business as usual. That's not the way it should be done.

I long for the days when the "ping of death" elicited a new kernel IN LESS THAN ONE DAY! (Alan Cox).

Jim

(Log in to post comments)

Re: Bad Maintainance!

Posted Dec 2, 2003 20:03 UTC (Tue) by crimsun (subscriber, #13750) [Link]

I think it's a fundamental difference in how a maintainer follows the rigor of his release schedule. The argument has been made that people who track exploits closely will patch their systems regardless of whether a version bump is made to accomodate the release of a critical fix. I feel Marcelo's doing a fine job maintaining 2.4. Yes, Alan's policy with 2.2 has always been more finely-suited to security releases reflecting version bumps. That way there is no confusion.

The original closing hook really stands; we all need to be watching cset merges.

Re: Bad Maintainance!

Posted Dec 2, 2003 21:20 UTC (Tue) by freethinker (guest, #4397) [Link]

I don't agree. Yes, we can have some people, who have the skills and time to track exploits, patch their systems. But wouldn't it be better if the maintainer patched the kernel and issued a new release with an appropriate message regarding the urgency? Then many more people would be aware and would upgrade. That's what the maintainer is for: to track these things, to be aware of urgent issues, and to do the right thing with them.

I won't go so far as to say that Marcelo fell down on the job here. I don't know all the circumstances. But the question should be asked.

Bad Maintainance!

Posted Dec 2, 2003 21:29 UTC (Tue) by smoogen (subscriber, #97) [Link]

Let me follow your logic:
Linus, Andrew, Alan, et al dont think of it as a security bug fix, but more of a cleanup and possible problem. They dont tell people to stop using 2.6.0.x and go to the next test version.
Marcelo applies the patch and is supposed to know that it is a security bug fix of great importance.

I have thought that Marcelo was pretty slow during his Connectiva days.. but this is a bit ridiculous.

Bad Maintainance!

Posted Dec 2, 2003 22:14 UTC (Tue) by LogicG8 (guest, #11076) [Link]

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.

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.

Bad Maintainance!

Posted Dec 2, 2003 23:22 UTC (Tue) by jafo (subscriber, #8892) [Link]

The issue is that the security implications weren't fully realized before the compromise of the Debian systems.

My problem with the 2.4.23 release is that it is (IMHO) much more than just a maintenance release. Adding USB gadget drivers, IPVS, SCTP, and others seems well beyond what I'd think of in a maintenance release. These can often cause other patches to fail to apply, making it difficult for admins to get their systems up to date.

Sean

Bad Maintainance!

Posted Dec 4, 2003 17:51 UTC (Thu) by hazelsct (subscriber, #3659) [Link]

I cannot agree with you regarding this particular flaw, as the nature of the bug was not known to people maintaining the code.

But I do agree regarding your earlier example. Alan's practice with 2.2 has been to make a new point release as soon as a vulnerability is discovered and patched, a release which *only* fixes the vulnerability (saving all other developments for the subsequent point release). This greatly simplifies keeping track of secure kernel releases, rather than having to know exactly which revision fixes things for each separate distribution. (For example, "You have 2.4.19-15? Is that RedHat, SuSE, Mandrake or TurboLinux? Let's see, I can't remember exactly which one fixed that problem for your particular distribution...") Marcelo has not done this, and I wish he would commit to doing so moving forward.