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?

[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?

[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: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.

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.