Forgot your password?
typodupeerror
Security Software Upgrades Linux

A Flood of Stable Linux Kernels Released 105

Posted by timothy
from the five-is-better-than-one dept.
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."
This discussion has been archived. No new comments can be posted.

A Flood of Stable Linux Kernels Released

Comments Filter:
  • unknown? (Score:4, Insightful)

    by Lord Ender (156273) on Wednesday July 07, 2010 @04:18PM (#32830912) Homepage

    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)

      by Aboroth (1841308) on Wednesday July 07, 2010 @04:24PM (#32831024)
      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? (Score:5, Informative)

      by Enderandrew (866215) <enderandrew@g m a il.com> on Wednesday July 07, 2010 @04:25PM (#32831038) Homepage Journal

      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)

        by Lord Ender (156273) on Wednesday July 07, 2010 @05:01PM (#32831708) Homepage

        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? (Score:5, Insightful)

          by adolf (21054) <flodadolf@gmail.com> on Wednesday July 07, 2010 @05:26PM (#32832134) Journal

          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)

            by kbielefe (606566) <karl.bielefeldt+slashdot@gma i l . c om> on Wednesday July 07, 2010 @08:05PM (#32833880)

            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)

              by Anonymous Coward

              apt...har har

        • 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

          • 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.

            • 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

              • 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.

              • by aiht (1017790)
                Enderandrew arguing with Lord Ender?
                What is this, an Orson Scott Card convention?
        • by s.d. (33767)

          /. 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

        • 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.

        • by mysidia (191772)

          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

        • 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.

        • by Eil (82413)

          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.

      • by mysidia (191772)

        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,

      • 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)

      by compro01 (777531)

      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)

      by 0racle (667029) on Wednesday July 07, 2010 @04:30PM (#32831100)
      Since Linus decided security holes and bugs are not any different [daniweb.com] 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: (Score:2, Funny)

        by 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."

    • by mysidia (191772)

      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.

    • Here, let me fix TFA for you:

      Greg Kroah-Hartman, released one new stable kernel today and made backport commits to four other "stable" long-life development trees. GKH went on to make a vague comment on folks using the 2.6.27 tree, needing to re-base to the current changes. Since nothing else new and exciting was going on, we thought we could merely speculate on our blog, and then post a sensationalist summary to Slashdot. Then we just had to sit back and watch the money roll in from the ad-revenue.

      Serio

  • 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"

    • by The MAZZTer (911996) <megazzt@g m a il.com> on Wednesday July 07, 2010 @04:48PM (#32831432) Homepage
      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. [microsoft.com]
    • Reading the topic summary, my first thought was "how boring", and apparently I'm not alone, considering that the third reply in has really nothing to say on the subject other than "Linux is better than Windows".

      What does Windows done wrong have to do with a flood of stable Linux kernels being released?

    • by Blakey Rat (99501)

      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

      • by Zakabog (603757)

        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

    • by heffrey (229704)

      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!!

      • 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)

      by kiwix (1810960)
      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...
    • 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...

  • by bl8n8r (649187) on Wednesday July 07, 2010 @04:34PM (#32831180)

    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)

      by Anonymous Coward

      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.

      • 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 [kernel.org] will let you look at that commit, what files changed, what log messages were included, who made it, etc.
        • Re: (Score:1, Informative)

          by Anonymous Coward

          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:3, Informative)

        by compro01 (777531)

        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

    • bash: telnet: command not found

  • I understand that this means that the different linux kernel families all have updates released, but I don't understand why you need fixe or six concurrent kernel branches. Not to be a troll, I just don't know why. It seems like a lot of work for not a lot of return.
    • Re: (Score:2, Insightful)

      by 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).

    • by Hatta (162192)

      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?

      • by mandelbr0t (1015855) on Wednesday July 07, 2010 @05:39PM (#32832344) Journal
        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.
      • by MikeyO (99577) on Wednesday July 07, 2010 @07:31PM (#32833628) Homepage

        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.

        • 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

          • by MikeyO (99577)

            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.

            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)

    by bradgoodman (964302) on Wednesday July 07, 2010 @05:53PM (#32832554) Homepage
    "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....

  • Kernelnewbies (Score:5, Informative)

    by JonJ (907502) <jon.jahren@gmail.com> on Wednesday July 07, 2010 @07:05PM (#32833346)
  • Wonder if it is time for Linux to drop 2. prefix, like with Java.

The most delightful day after the one on which you buy a cottage in the country is the one on which you resell it. -- J. Brecheux

Working...