A Flood of Stable Linux Kernels Released

Julie188 writes "Greg Kroah-Hartman has released five new stable Linux kernels, correcting minor errors of their predecessors and including improvements which are unlikely to generate new errors. As so often with kernel versions in the stable series, it remains undisclosed if the new versions contain changes which fix security vulnerabilities, although the number of changes and some of the descriptions of those changes certainly suggest that all the new versions contain security fixes."

Comments

unknown?

[Lord Ender]

Since when does the kernel team practice security-through-obscurity? It is essential to know when security fixes are available. Many organizations only patch stable systems if there is a security problem.

Re:unknown?

[Aboroth]

Since each kernel comes with a complete changelog, it is only "unknown" to people who aren't capable of reading it. It has always been the responsibility of those who build kernels to pay attention to this. I don't recall there ever being a special designation on the front page of kernel.org to designate kernels that fix security vulnerabilities. If you go through a vendor I'm sure they keep up on this or they are incompetent. If you patch your own kernels then you should pay attention to the changelogs. As always.

Yay for sensationalist writing.

Re:unknown?

[Enderandrew]

This has been the policy of the Linux kernel for ages.

They don't go out of their way to hide security fixes, but they don't advertise them either. All bugs are treated as bugs. You can read the lengthy changelog.

Linus doesn't believe in calling special attention to closed bugs, because it also alerts people that there are unpatched security holes in earlier versions. Some shops don't patch Linux boxes regularly.

Re:unknown?

[0racle]

Since Linus decided security holes and bugs are not any different then a bug that causes your screen to refresh a microsecond slower. They list everything as bug fixes and don't differentiate on the potential severity of the bug.

Re:unknown?

[Lord Ender]

Alerting people that there are unpatched security holes in earlier versions is exactly what he should be doing. Perhaps they don't prioritize vulnerabilities differently in their development process internally, but those of us who use their software certainly treat security problems differently! /. car analogy warning: would you rather buy a car from a company that treated a recall about the engine exploding and killing you the same way they treat a recall about the light in the trunk failing?

Re:unknown?

[adolf]

If you don't like the way things are announced, change it. There's absolutely nothing in the world to prevent you from condensing the kernel changelog into a list of security problems that have been fixed, and then publishing your findings in a concise and easy-to-digest form for others to consume.

Re:unknown?

[Anonymous Coward]

--
"I use a Mac because I'm just better than you are."

"Me too, but I quote myself in my message body, not my sig."

Re:unknown?

[kbielefe]

This is exactly what distributions do. Only people who really know what they're doing get their kernels directly from kernel.org. Even if you know what you're doing, it's still more convenient for most people to just get security updates from their distro.

A more apt analogy is a car manufacturer putting out a list of recalls, and your dealership giving you a personal call when the most serious recalls are needed.

Re:2010: Year of the Linux Desktop

[jim_v2000]

For a lot of people it is, for a lot people it isn't.

fixes are fully disclosed, stop fud'ing

[bl8n8r]

The disclosures aren't in a pretty clicky-clicky-box but the kernel devs *do* strive to maintain formats which cater to the major users:

for shell ninjas:
    wget www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33 -O - | less

for geezers/people with lawns:
    telnet ftp.kernel.org 21

for the lamer++:
    http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

Re:fixes are fully disclosed, stop fud'ing

[compro01]

If you don't know what that means, you're probably not a member of the 2% or so of users who manually upgrade their kernel and thus probably don't need to worry about it. These updates to your system will be handled by the maintainers of whatever distro you use.

Though to summarize that one, it's undoing a fix (the original issue caused the kernel not to build) to some initial setup code (find the terminal, initialize additional CPU cores, etc.) for the Itamium processor which would cause genksyms (GENerate Kernel SYMbolS, which generates symbol version (checksum of all the typedefs, structs, unions, etc. in the kernel down to their base types) information) not to work properly as it fails to generate the checksum for a particular variable in a struct.

Re:2010: Year of the Linux Desktop

[Eternauta3k]

Yup, this kernel fixed the task-switching problem that was keeping the general public from using linux as their main OS. Take that, Microsoft!

Re:If this were Windows

[The MAZZTer]

Microsoft has since the leak you described moved "bugward compatibility" into something called "shims". They are basically compatibility fixes that only affect specific applications, to ensure newly written apps won't run into the compatibility hacks. More info.

Re:Variety is the spice of life

[Anonymous Coward]

Because there just aren't enough rolling release distributions out there. Instead we have things like Ubuntu's LTS releases which hang on to kernels forever (2 years or so which is long enough for around 8 to 10 kernel release cycles).

Re:Variety is the spice of life

[mandelbr0t]

Because all the distro's packages were tested against kernel 2.6.27. Integration testing is a badly overlooked phase by many distros. However, I've seen that Debian-based stuff undergoes extensive integration testing, thus making a kernel version upgrade a huge testing process. Fixing the bug in the kernel version used by the distro saves a lot of testing time, and is much less likely to break distro-specific applications.

Oxymoron

[bradgoodman]

"Flood of Stable Kernels"

Last time we sent our customers a "flood of stable releases" we got an angry letter from them...something about Quality Control....

Revision ids in the GIT repository...

[mengel]

Those big long hex numbers are revision id's in the GIT version control system used for the kernel. Perusing any instance of said repository (such as the one here will let you look at that commit, what files changed, what log messages were included, who made it, etc.

Re:Who cares?

[Flossymike]

Well I like Monkey Island :-)

Re:Who cares?

[Anonymous Coward]

I'm glad to hear you attended your family reunion.

Re:If this were Windows

[kiwix]

The main reason for this is that the vast majority of Windows programs are Closed Source, while the vast majority of Linux programs are Open Source. When a change in the kernel breaks an Open Source program, it's no big deal because any one can fix the program. With a closed Source program, you have to wait for the author to fix the program, assuming that he still cares about the program...

Kernelnewbies

[JonJ]

Always has a nice human readable summary of the changes.

Re:Variety is the spice of life

[MikeyO]

This might have been a more reasonable thing to do when we had the "even numbered" series (2.0, 2.2, 2.4) for stable kernels and "odd numbered" (2.1, 2.3, 2.5) kernels for new features. But now 2.6 is where both stable kernels and new development is released from, So things you might have been relying on could drastically change from one stable release to the next. For example, the entire devfs subsystem was removed completely in kernel 2.6.13. If you had something that depended on the existence of devfs, you could not upgrade to 2.6.13 or later until you got rid of your dependance on devfs.

Re:If this were Windows

[shutdown -p now]

This is a pretty sharp contrast with Linux programming where such stunts as using the OS in unconventional was is at the very least severely frowned upon

I can assure you that using undocumented APIs, or relying on undocumented behavior and effects of public APIs, is very much frowned on by Microsoft developers as well. You only need to read Raymond Chen's blog to find that out...

Re:2010: Year of the Linux Desktop

[Cwix]

Yay.. looks like its the year of the XP.. still...