A Flood of Stable Linux Kernels Released 105
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."
Re:unknown? (Score:5, Informative)
Yay for sensationalist writing.
Re:unknown? (Score:5, Informative)
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? (Score:5, Informative)
fixes are fully disclosed, stop fud'ing (Score:5, Informative)
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 [kernel.org]
Re:If this were Windows (Score:5, Informative)
Re:fixes are fully disclosed, stop fud'ing (Score:1, Informative)
I'm a programmer by trade but this change log is absolutely useless to me. For example:
Revert the change made to arch/ia64/sn/kernel/setup.c by commit
204fba4aa303ea4a7bb726a539bf4a5b9e3203d0 as it breaks the build.
Fixing the build the b94b08081fcecf83fa690d6c5664f6316fe72208 way
breaks xpc because genksyms then fails to generate an CRC for
per_cpu____sn_cnodeid_to_nasid because of limitations in the
generic genksyms code.
What the fuck does that even mean and how does it affect an average user? How am I supposed to know if this is a security problem or not? This resembles a commit log, not a change log.
Re:Variety is the spice of life (Score:4, Informative)
Revision ids in the GIT repository... (Score:4, Informative)
Re:Who cares? (Score:2, Informative)
Well I like Monkey Island :-)
Re:Revision ids in the GIT repository... (Score:1, Informative)
Fair enough but that still doesn't give me any idea of what was actually fixed from an end user perspective. I still don't know what configurations the fix might affect. I still don't know if it's a security issue.
Take this article from Microsoft for example:
http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx
It says in plain English which versions of the software will need the patch and how the flaw might be exploited. It even gives an estimate of how critical the vulnerability could be.
I think this is the kind of thing that the submitter is looking for when he says "it remains undisclosed if the new versions contain changes which fix security vulnerabilities".
Re:fixes are fully disclosed, stop fud'ing (Score:3, Informative)
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.
Kernelnewbies (Score:5, Informative)
Re:Variety is the spice of life (Score:5, Informative)
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 (Score:3, Informative)
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:unknown? (Score:5, Informative)
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:Revision ids in the GIT repository... (Score:1, Informative)
If you want information digested in that way, maybe you should use get kernel updates from a Linux distribution, not from the kernel developers.