Debian Planet










Welcome to Debian Planet

Search

Apt-get into it.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers' Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You're not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International

  • DebianWorld

    (Français)

  • DebianForum.de

    (Deutsch)

  • EsDebian

    (Español)

  • Debian-BR

    (Português)

  • DebianUsers

    (Korean)

  • MaximumDebian

    (Italiano)

  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on irc.debian.org.

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you've written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.

    Sponsorship

    DP is sponsored by uklinux.net and CheepLinux.

    Debian Planet runs on hardware donated by Xinit systems and is using kieser.net's bandwidth.

    Who's Online

    There are currently, 22 guest(s) and 2 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

      
    Debian Has Slow Security Updates?
    Contributed by Anonymous on Tuesday, January 15 @ 05:16:06 GMT

    Security
    Some comments on the Linux Today story about the recent glibc security update challenged my perception that Debian is very responsive to security problems in core packages. Basically, they say that this vulnerability was reported on December 14th. Has it really taken one month to deliver a core glibc update?

    This brings up a larger issue regarding security for me. I regularly run Nessus against our Deb boxes and see reports about vulnerabilities in OpenSSH and other packages. I was always under the assumption that the bug fixes were back ported to the stable version used in Potato and that Nessus was detecting the version of the package, not the existance of a real vulnerability. If I was wrong about Deb having the fastest security updates out of the shoot, maybe I am wrong about other assumptions. Can anyone give me a definitive answer?

    I have always considered the slow moving profile of the stable tree one of the most stable and secure versions of Linux simply because of the care that is taken in the security updates and application versions. Am I being blinded by my love of apt-get or is there nothing here but FUD?

    DanielS: Both myself and Martin "Joey" Schulze, as it turns out, sent emails to LWN to clarify the reasoning behind this. glibc is obviously both a huge and critical package, and this hinders the speed of getting updates in. m68k and arm are possibly the two slowest architectures in Debian today, and they were both released with potato, thus glibc had to be built on both of those before the DSA could be released - ever tried to build glibc on an m68k? Also, the package had to be thoroughly tested, as it is arguably the most critical package.

    Joy: as for Nessus, all of the checks that merely compare the reported software version against a known vulnerable version are going to be flawed for Debian stable. Arguably, any checks that rely merely on the reported version string are pretty lame.

     
    Related Links

  • More about Security
  • News by DanielS

    Most read story about Security:
    Why Debian is still not as secure as OpenBSD ?

    Last news about Security:

    Printer Friendly Page  Send this Story to a Friend
  • "Debian Has Slow Security Updates?" | Login/Create Account | 9 comments
    Threshold


    The comments are owned by the poster. We aren't responsible for their content.

    Re: Debian Has Slow Security Updates? (Score: 2, Insighful)
    by GehRehmee on Tuesday, January 15 @ 06:15:14 GMT
    (User Info) http://rifetech.com/~gehn/bg/

    Okay, I understand that certain architectures take longer to produce working packages for. But does it really make sense that the post of a security fix for i386 should be held back because it can't be immediately released on m68k, or vice-versa?

    Maybe if i386 started pulling ahead for security fixes, it might encourage people to focus more on the portability issues to keep their platform of choice up to par with the competition.

    [ Reply ]


    Re: Debian Has Slow Security Updates? (Score: 1)
    by gwolf (gwolf at gwolf dot cx) on Tuesday, January 15 @ 18:05:52 GMT
    (User Info) http://www.gwolf.cx

    DanielS:

    Besides using a cross-compiler (as gcc itself) as someone else suggested on the list... Has anyone tried using a (good) emulator? I recently installed UAE -which is part of Debian already- on an Athlon system. The Amiga being emulated, when I asked it to work at full host system speed, was so fast I had a very hard time double-clicking with the mouse! 😉

    I know that UAE does not emulate the MMU... Here is the patch, however, to make it able to boot Linux (for UAE 0.8.20.2). A quick look at the patch reveals it implements a MMU.

    Of course, I would not treat packages tested against an emulated Amiga to be 100% fine... But you can build there and later try the binaries at a real m68k...

    [ Reply ]


    ONE MONTH to build/test on m68k?? (Score: 1)
    by hazelsct (hazelscq@mit.edu) on Wednesday, January 16 @ 00:04:22 GMT
    (User Info) http://lyre.mit.edu/~powell/

    Okay, so m68k is slow. But even on ARM (one of my arches), building all of X 4.1 takes a few hours, how much bigger can glibc be?

    Re: testing, isn't there quite a bit of testing built into the build process for glibc? Can it possibly take that much more time to test on m68k than i386?

    As a user of slow(er) arches, I really can't believe that more than a tenth of this one-month delay has been caused by build/test speed.

    [ Reply ]


    Based on: PHP-Nuke

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2000 by Debian Planet

    You can syndicate our news using the file backend.php.