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."
unknown? (Score:4, Insightful)
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? (Score:5, Informative)
Yay for sensationalist writing.
Re: (Score:2, Informative)
Well I like Monkey Island :-)
Re: (Score:3, Funny)
I'm glad to hear you attended your family reunion.
Re: (Score:2)
It'll never be ready for your desktop. For me, I already use it every day and although there is stuff that pisses me off it meets my needs fine.
Re: (Score:2)
It's been on many people's desktops for years, troll. If almost every computer made didn't come with Windows, Linux would be the dominant OS. As it is, only people who understand computers use it. I've installed Linux on computer noobs' PCs, and all of them like it better than Windows.
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:4, Insightful)
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: (Score:1)
Right... you mean Ford builds many of their engines.. there are exceptions [wikipedia.org]
Would you expect Yamaha to be the company to issue the recall for Ford Taurus SHO V-8's, if a defect of some sort were ever found with the SHO V8 engine?
Re: (Score:2)
Mazda also co-designed and makes some engines for Ford.
Re:unknown? (Score:5, Insightful)
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? (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: (Score:1, Funny)
apt...har har
Re: (Score:2)
The car analogy fails.
You're suggesting a security bug guarantees a systemic failure, when really it just means there is a possibility (not even a probability) that you could be exploited under a very specific circumstance. And even then most kernel vulnerabilities should be protected by other means.
However, another bug might cause your partition to corrupt, your system to perform slower, or your system to crash.
One could contend all of those issues are closer to your engine exploding, and more severe than
Re: (Score:2)
The mistake you are making is that you are forgetting that confidentiality is the most important property of many sorts of data. Availability and integrity are important, too, but companies routinely test to ensure their systems are reliable with a given system version.
Bugs with could allow sensitive data to be disclosed are fundamentally more important. Treating them the same is a disservice to customers.
Re: (Score:2)
You're saying the potential for a kernel-level vulnerability (which hardly should matter because you should have other security methodologies in place) is more important that a bug which corrupts all your data, or breaks your system?
I have to disagree.
Now if you said a bug which GUARANTEES confidential data was trasmitted to others, I'd agree that is as critical as they come.
But that is not what we're talking about.
You're also skipping the second half of my last message. Most shops either never patch, or pa
Re: (Score:2)
You're saying the potential for a kernel-level vulnerability (which hardly should matter because you should have other security methodologies in place) is more important that a bug which corrupts all your data, or breaks your system?
It depends on the role the machine is filling. Consider a financial or medical imaging server, which contains scanned copies of paper records. In cases like that, having the server crash and losing all of the (backed up) data is FAR preferable to said data being stolen.
Re: (Score:2)
Re: (Score:1)
What is this, an Orson Scott Card convention?
Re: (Score:2)
/. 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?
I don't think your analogy is right. Think of it more like the company that produces a car engine and doesn't necessarily make sure every person understands whether it's the engine spontaneously catching fire or the finish peeling. They say "this is the list of shit we fixed" and articulate everything they fixed and how they fixed it.
You bet your ass that Toyota will tell you if it's an exploding problem or a finish peeling problem. The distros, in every update, will tell you what bugs were patched, and
Re: (Score:2)
Alerting people that there are unpatched security holes in earlier versions is exactly what he should be doing.
Do you follow the security notices of every package you have installed? I have 1,665 packages on my Ubuntu netbook. Each of those has a maintainer who's in charge of paying attention to that stuff for me and updating that package if something important comes along.
Same with the kernel itself: Linus tells the distro maintainers and the distro maintainers tell you.
Re: (Score:1)
The Linux kernel developers don't make an operating system, they make a kernel. Downstream vendors do (Redhat, Ubuntu, Debian, etc), and the downstream vendors will keep track of changes to the upstream kernel, it is their responsibility to bring down security patches, build a fixed kernel, and deliver the fix to the end users.
If a design defect in a type of engine caused it to explode, wouldn't you expect the manufacturer of the cars to issue the recalls on products that use the effected type of engine
Re: (Score:2)
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?
Yes. I like my Toyota, thank you very much.
Re: (Score:2)
The releases made by kernel.org are intended for software distribution maintainers, developers, and the odd crazy DIYer. Not end users. If you get your operating system from Red Hat or Canonical, it's their job to tell you that there is a security issue and by the way here is the patch.
Re: (Score:1)
Some shops don't patch Linux boxes regularly.
Because the non-advertisement of security issues allows them to have a false sense of security. If it were noted more prominently that a certain security bug were fixed in a certain version, those people who don't patch Linux boxes regularly would be more inclined to make an exception.
Security is important to these people, just like system integrity is.
It is irresponsible to not draw attention to bugs that allow easy intrusion, execution of arbitrary code,
Re: (Score:2)
Some shops don't patch Linux boxes regularly.
Bah! I patch weekly. ...but I only reboot about once a decade.
Like Novel said: "For servers that only go down when you bring them down"...
Re: (Score:2, Insightful)
Either the links weren't in TFA when the submitter posted this or they were too lazy to follow them.
there's a list of changes here [gmane.org].
Re:unknown? (Score:5, Informative)
Re: (Score:2, Funny)
--
"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: (Score:1)
According to the slashdot article:
it remains undisclosed if the new versions contain changes which fix security vulnerabilities,
That would mean they are not published in the publicly viewable changelogs, as publishing in the changelog would be disclosure.
Re: (Score:2)
Here, let me fix TFA for you:
Serio
Re:2010: Year of the Linux Desktop (Score:5, Insightful)
Re: (Score:3, Funny)
Yay.. looks like its the year of the XP.. still...
Re: (Score:2)
At least on Internet-facing computers according to the hitslink numbers, Linux' market share is very stable at around 1%. Since February 2009 it's been in the range 0.94-1.17& with the last being 1.07%. However, the total PC market is still growing rapidly so in a way it's healthier than ever, at the last guesstimate there's an installed base of about 1.4 billion computers - that's 14 million Linux users.
It really depends on how you look at it, in relative figures it's still struggling. But if you belie
Re: (Score:1)
Wikimedia: 1.8% [wikimedia.org]
W3Counter: 2.78% [w3counter.com]
W3Schools: 4.5% [w3schools.com]
Re: (Score:3, Funny)
Re: (Score:2)
oh, I get it, ees joke! BWAHAHAHAA ! Veery gud!
Re: (Score:2)
If this were Windows (Score:1, Offtopic)
Okay HERE is what I will begin citing about what is wrong with the culture of Windows programming.
I am not going to claim that in every case, any given program compiled to run on Linux will not break because of a "fix" to the kernel, but I will say that it is very uncommon and very unusual for this to happen.
Thanks to the Windows source code leak years ago, we now know for certain that "bugward compatibility" is built into the Windows OS and its kernel. In case you can't guess what "bugward compatibility"
Re:If this were Windows (Score:5, Informative)
My first thought... (Score:2)
What does Windows done wrong have to do with a flood of stable Linux kernels being released?
Re: (Score:2)
Congratulations on being completely off-topic, yet getting modded up.
Thanks to the Windows source code leak years ago, we now know for certain that "bugward compatibility" is built into the Windows OS and its kernel.
1) No matter how many times you type "bugward compatibility" it's not going to catch-on, ok? Your phrase coining is not working, give it up already.
2) That's all been moved into shims, so only the specific application that needs that specific bug is affected now. Every other application gets the
Re: (Score:2)
Look how many developers on this site alone were bitching and moaning about UAC when Vista and Windows 7 added that in. Hey buddy: your program triggers UAC prompts *because it is buggy!!* The only thing that changed from XP to Vista, permissions-wise, is that Microsoft's attitude changed from "grin and bear it" to "let's give these developers a little hint that their apps are broken."
Yes, we all know a program is horribly broken when it wants to be installed somewhere crazy like in the %Program Files% directory...
UAC was a hacky way of defending against malware (it worked for a little while till malware writers found ways of going around it.) On Vista it's been nothing but a nuisance, I've never seen it actually stop anything unwanted from running though I have observed many users growing so used to the pop up that they disregard it without reading (since it pops up so frequently.) On W
Re: (Score:2)
Yeah it really sucks that programs that run on one version of Windows keep on running on versions released far into the future. I really hate it when I can run my old programs. It just drives me mad. I wish the MS would make all my old programs break when they release new versions of Windows. Heck, I might just buy a Mac!!
Re: (Score:1)
I am running software written for OS X 10.0 on a PPC, on my Intel Mac under 10.6 and it works great. If I need to run software going back to the 80s I can, using an older Powerbook that still works great after 15 years, or a slightly newer Powerbook that replaced it 7 years later which of course runs OS X.
I know the fashion is to bash on Apple, but it was possible to run truly ancient code on a Mac until the burial of OS 9. OS X applications are compatible across platforms and backwards compatibility is p
Re: (Score:2, Insightful)
Re: (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: (Score:2)
Accidental anon post, sorry. It was mine, of course.
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: (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.
Revision ids in the GIT repository... (Score:4, Informative)
Re: (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
Re: (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.
Re: (Score:2)
And Linux distributions condense it into similar formats:
http://www.debian.org/security/2010/dsa-2012 [debian.org]
Re: (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
Re: (Score:2)
bash: telnet: command not found
Variety is the spice of life (Score:2)
Re: (Score:2, Insightful)
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: (Score:2)
Yeah, I don't get it. If there's a bug in kernel 2.6.27, why patch it to 2.6.27.48 instead of upgrading to 2.6.34?
Re:Variety is the spice of life (Score:4, 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: (Score:2)
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.
And if we were still using the old version number format, and devfs had been removed in 2.7.13 or 2.8.0 rather than 2.6.13, you still would not be able to upgrade to that version or later until you'd removed your requirement for devfs. Features would still tend to be introduced in the same order, after all—they'd just be even later in getting to actual users. You get the same effect by freezing your distribution at, say, 2.6.27, and backporting only security patches and bugfixes until you're ready for
Re: (Score:2)
Yes, but if the new features were going into 2.7.x instead of 2.6.x, you'd not need to worry as much about upgrading to 2.6.latest in order to get the latest bugfixes, as Hatta was asking about above.
Oxymoron (Score:4, Insightful)
Last time we sent our customers a "flood of stable releases" we got an angry letter from them...something about Quality Control....
Kernelnewbies (Score:5, Informative)
Re: (Score:1)
How long will it take to move to 2.8?
Probably forever. [wikipedia.org] This reflects changes in the development methodology followed by the kernel team(s).
It seems to have been a very long time now that the kernel has been in 2.6-land and people make a big deal about changes in that third group of digits. Is significant progress really being made?
Yes, it is. The amount of work done is not dependent on changes to the major version number.
There has probably been more progress between 2.6.0 and 2.6.34 than there was between 2.2 and 2.4, or 2.4 and 2.6.0.
Time to drop 2? (Score:2)