Forgot your password?
typodupeerror
Debian Security

Debian Struggling With Security 264

Posted by Zonk
from the invaders-at-the-gates dept.
Masq666 wrote to mention a ZDNet article discussing difficulties Debian is having with security updates. From the article: "...Lack of manpower also appears to be adding to Debian's security woes. Michael Stone, another member of Debian's security team, expressed his frustration to the organisation's security e-mail mailing list in mid-June, saying there was no effective tracking of security problems."
This discussion has been archived. No new comments can be posted.

Debian Struggling With Security

Comments Filter:
  • by VisualVoice (592060) on Tuesday July 05, 2005 @05:40PM (#12989059)
    They have a huge team focusing on security.
    • by sharkey (16670) on Tuesday July 05, 2005 @07:08PM (#12989670)
      They have a huge team focusing on security.

      Too bad none of them work at Microsoft :(

  • Pick any two (Score:5, Insightful)

    by mcrbids (148650) on Tuesday July 05, 2005 @05:41PM (#12989063) Journal
    Secure, Convenient, Cheap.

    Pick any two.

    (General rule, but it does generally follow)
    • by diamondsw (685967) on Tuesday July 05, 2005 @06:04PM (#12989248)
      Or pick Windows and get none!
    • I thought it was secure, fast, cheap. And I thought I knew which two Debian had picked :)
    • Re:Pick any two (Score:5, Interesting)

      by HawkingMattress (588824) on Tuesday July 05, 2005 @06:17PM (#12989339)
      Yep but it doesn't apply here. Debian can be secure, convenient and cheap. It could probably be more secure and less convenient but still it is generally a very secure distro... and it's certainly cheap and convenient too
      The problem is not that you can't mix those three in debian particular setting, it's that the debian team seems to serverely lack redundancy. Read: one person has obligations somewhere else and the whole stable security updates process hangs !
      I really hope that Debian is going to make something about it fast, and in a definitive way. I don't want to run something else than debian, really. But this is really embarassing, especially if you have production servers running sarge. And this situation ain't new, Slashdot was very slow to catch it but i read about it last week. Things haven't moved a lot since (well 1 security update was released, but some major exploits have been found in iirc at least two other packages, and nothing coming yet... Other distros had everything fixed by the end of last month)

      I think Debian should clarify the issue, and call for help if it's necessary. And maybe simplify the whole debian democratic process if as it seems from the outside every decision has to go through days and days of pointless discussion.
    • Re:Pick any two (Score:2, Interesting)

      by GNUALMAFUERTE (697061)
      Slackware is secure.
      Slackware is convenient (I Know that many will say otherwise, but if you have Unix experience, it's the best solution, really easy to manage)-
      It's cheap, it doesn't contain any proprietary software.

      Also, Debian can be as safe as Slackware, the problem with this kind of Distro (Debian) is that the people using it pretends that someone else takes care of their security. A Sysadmin doesn't need some stupid organization to submit patches to him automatically or anything like that. He just h
  • by Geekboy(Wizard) (87906) <.spambox. .at. .theapt.org.> on Tuesday July 05, 2005 @05:42PM (#12989073) Homepage Journal
    $ apt-get update security-officer

    Problem Solved.

    (Its funny. Laugh.)
  • by frovingslosh (582462) on Tuesday July 05, 2005 @05:43PM (#12989076)
    there was no effective tracking of security problems

    Now that this has been published on /. it will have to be revised to "no effective tracking of security problems by the good guys".

  • by Gorath99 (746654) on Tuesday July 05, 2005 @05:44PM (#12989084)
    Disturbing to see how the distro that was always renowned for its reliability is now having such troubles.

    I wish the debian team all the luck in the world in fixing this matter. They're in a difficult position now that they're both lagging behind (though much less so than a while back) and cannot claim unparalleled reliability.
    • I wish the debian team all the luck

      I think this is probably part of the problem... too many people are wishing them luck and not enough people are actually doing anything to address the problem.

      • I think this is probably part of the problem... too many people are wishing them luck and not enough people are actually doing anything to address the problem.


        Well you have to admit, the Debian elite have not exactly been known to welcome new users with open arms. Don't get me wrong, I really have a great admiration for their work, but it would seem to me the best source of new developers would be from a pool of motivated users.
    • First, there is a policy problem here. If a security update is not available due to lack of build systems for a specific architecture (ARM), well so be it. It should not hold the updates for all remaining architectures the way it does now.

      And if someone wants to see security updates for this specific architecture (ARM) they might as well donate. The only ARM motherboards useable for a build system are the developer toolkits and these cost money.
      • While not personally familiar with how the builds in Debian happen, a cross compiling build system is how a lot of vendors deal with this very issue.

        I know of vendors that support equipment they don't have a single sample of. Of course, they warn their customers and typically have one or a very small number of early-adopter customers who maybe get a good price break or simply want new features enough to explicitly desire bleeding edge to serve as testing for their releases.
    • by tacocat (527354) <tallison1@NOspam.twmi.rr.com> on Tuesday July 05, 2005 @07:23PM (#12989778)

      It would be a hell of a lot easier if they only supported X86 architecture like all those other Distros you refer to as the ones to lag behind.

      I think what they really suffer from, and I am not expert, is politics of a large system and the perception of lots of power sitting on top. I could be wrong.

      Regardless of what anyone might want to say against Debian, I still believe that they are extremely good at what they do and don't get credit for it. There is no other distro out there that attempts to support as many architectures as effectively (or at all) and if Debian decided to just delete them all except X86/X86-64 then their job would be a hell of a lot easier to execute.

      • by dmaxwell (43234) on Tuesday July 05, 2005 @08:22PM (#12990110)
        Supporting arches that span the gamet of bitness and endianness shakes out bugs and bad assumptions that can be hard to find otherwise. These fixes get pushed upstream whenever possible. So Debian is raising the water for a heck of a lot of boats. Until the great license blowup, Debian's X-Strike Force was also a major reason why XFree86 ran on so many platforms. The bit and endian issues THERE are a bitch.

        It might be better in some respects if Debian were x86 only like everybody else but we would all be poorer for it.
        • I really doubt that the Debian team was the major factor in getting XFree86 to run on multiple platforms, last I checked NetBSD and OpenBSD also used it prior to the license debacle and I'll bet ya they submitted patches too. And, since they both run on more platforms, they probably helped it work on so many platforms too.

          Perhaps it is better to say Debian's team contributed to XFree86's stability on multiple platforms.

      • I think what they really suffer from, and I am not expert, is politics of a large system and the perception of lots of power sitting on top. I could be wrong.

        Actually, I do think you're wrong, but I am biased in that I'm a Debian Developer. Developers only have to get involved in "politics" if they really wish, but the bulk of developers happily work on the half-a-dozen or so packages they're maintaining and leave the "politics" to the people who care about them. I consider myself amongst this group

  • by Anonymous Coward on Tuesday July 05, 2005 @05:44PM (#12989086)
    The tone of the story would be laden with arrogance and derision towards the "Borg", painfully unfunny and unoriginal jokes would follow, and everyone would point to Apple and Linux as the greatest and secure OSes on the planet.

    But since it's not Microsoft, it's a fairly sober writeup, and Microsoft jokes would just follow a little bit later.

    Funny how things work here at slashdot. no i'm not new here. I'd just figure some people would grow up sooner or later.
    • The thing you're not taking into account is that Debian's security team, while having a professional attitude, are volunteers. Microsoft has more money than it can spend (legally), so has no excuse in terms of "lack of manpower", unless they don't exist on the planet.

      Come to think of it, perhaps they're all working at Microsoft? Or maybe Microsoft could help out the Debian guys by funding some FTEs for Debian's security team, since it will help secure the Internet (which runs for a large part on Debian sys
    • by Brandybuck (704397) on Tuesday July 05, 2005 @06:11PM (#12989292) Homepage Journal
      I'd just figure some people would grow up sooner or later.

      Oh we do indeed grow up. Unfortunately Slashdot has an unending supply of new posters straight out of kindergarten who have no problems at all firmly believing in the rightness of double standards and the logic of conflicting axioms.
    • And if it were Microsoft, the derision would be _justified_ motherfucker.
    • by Ernesto Alvarez (750678) on Tuesday July 05, 2005 @07:48PM (#12989927) Homepage Journal
      You've got to admit there is a fundamental difference that would also cause that change of attitudes.

      Debian security guys tend to have an attitude of trying to do things right. You're talking about the same people that chose to stop everything when they were compromised last year (and that was two days before a woody revision release). It's no surprise that people think of them as a good team without the necesary resources that need help. After all, they appear to do what they can with whatever resources they've got.

      Microsoft, however, is known for turning a blind eye to big problems, trusting no one will find out and trying to NDA the hell out of everyone. Considering people pay big $$$ to them, and they do play dumb more often than they should, guess what the attitude toward them would be.

      MS has been doing things a little better lately, but years of treating security like they did in the '90s aren't forgotten that easily.

      I like Debian, and really hope they can solve their staff shortage. I wouldn't like them to go under because of this.
    • If in order to make whatever your point is, you have to make up hypothetical opinions held by people you also made up under a hypothetical situation you also made up...

      You don't actually have a point at all.
  • Boring jobs (Score:4, Insightful)

    by ignorant_coward (883188) on Tuesday July 05, 2005 @05:47PM (#12989113)

    It isn't any suprise that the boring and the mundane tasks fall short in manpower.

    This is why there needs to be more commercial involvement in FOSS, so that people who just want a day job and a paycheck can do these sorts of things.
  • Too many packages? (Score:5, Interesting)

    by slavemowgli (585321) on Tuesday July 05, 2005 @05:48PM (#12989118) Homepage
    It's just a random thought, but have the Debian people ever contemplated whether their problems in this regard may stem from the fact that they have too many packages? The package list [debian.org] for the latest stable lists an incredible 16834 individual packages, and even though there are many programs which come in different flavours and thus contribute as more than one package, this still is a huge number.

    I can certainly see why security management gets a problem here. Maybe the Debian project should cut down on these and see just how many packages are really needed.
    • I wonder whether it's that, combined with the effort required to backport security fixes to versions that are often (let's face it) several years old. I'm not trying to start a flamewar, but I'm curious, why does backporting a security fix make for a more "stable" program then simply embracing a new version of the software that's been fixed upstream? It seems like the upstream people would do a better job anyway, as they are presumably more familiar with the software to begin with. Or is it when the Debi
      • by jpc (33615)

        It is certainly the case that many upstream maintainers really dont care about old versions of their software (and if different distros are using different old versions so much the worse). The problem is if it is something that other packages depend on and you end up in a hell of many twisty interfaces all different.

        I wouldnt support packages in stable that cannot guarantee to keep their interfaces stable for a reasonable period. They could be available as addons with no guarantees of secutity fixes.

        I thi
      • The idea, I think, is that new versions of a program might introduce behaviour changes that you don't want to force on people running production systems and just updating packages to fix security holes - so yes, that's what I'd say "stable" means. It not only tells you that the software is (supposedly) tested and tried, but also that you will not get unrelated changes even when you update within that branch.

        This is why projects will often release updates to older branches when a security hole is found, too
      • by lakeland (218447) <lakeland@acm.org> on Tuesday July 05, 2005 @06:15PM (#12989320) Homepage
        Consider a situation where a server has been set up and is running well in a company. That server has been working for several years, and while it may not have whiz-bang features, it keeps working every day just as well as it did the day before -- nothing ever breaks.

        Now, if a security issue is discovered in a package running on that machine, they do not want to upgrade to the latest release because they would worry about what it changes -- they want that one issue fixed and everything else to continue the same as before. Debian Stable is designed for people like this, the joke at the end of your post was actually close to the truth -- people really do want debian stable to be stable feature wise.

        Consider another situation, where somebody wants a fairly reliable and a fairly up-to-date server. When a bug is discovered, and especially security-related bugs, they'd like an updated package. On the other hand, they don't want to be sent the latest buggy software, they'd like it restricted to software that appears pretty stable. Debian Testing is designed for people like this.

        It sounds from your post that you cannot imagine people preferring a quirky, somewhat old, consistant distro over one kept up to date with bug fixes. I assure you that there is a large market for the stable distro, but if you are not in that market, there are plenty of others available.
        • the joke at the end of your post was actually close to the truth -- people really do want debian stable to be stable feature wise

          Actually, I wasn't joking, I wasn't sure if that was really the goal of stable or not.

          Granted, I haven't poked around the Debian website in a while, but it seems like they could do a little better job of explaining that. It was always my impression that you didn't get security updates with 'testing' and 'unstable'. Perhaps they should make more of a point of stating that yo

          • It was always my impression that you didn't get security updates with 'testing' and 'unstable

            This is (technically) correct. However, whenever a security bug is discovered in an unstable package, the uploaded version fixing it (usually just upgrading to the very latest package) is installed within a day -- some of the nomal double checking is bypassed for speed. Since fixing security bugs in unstable is so much easier than in stable, it happens quickly.

            Similarly for testing, any bugfix that corrects a s
        • The problem is that it takes a lot of effort to backport fixes. If an issue comes up and effects MyApp 1.0-5.0, chances are the fix I make to 5.0 does not work as-is for 1.0. So you need manpower not only to fix it, but to fix the fix. While there is a demand for such a distro, such a distro takes a lot of effort to maintain. The question is if the degree to which they do this is worth the cost. IMO, they go too far with it. But if thats how they want to spend their time, go for it.
          • Yes, exactly. And that is why unstable is not showing any of the security problems that stable is despite there being no team to help with security patches in unstable.
      • I've built my own "unstable on stable libc/perl" packages and after a while dependencies will kill you. The latest version of a package requires A, A requires B, B requires C, and the new version of C breaks a lot of things.

        Security backports require more effort, but they're unlikely to trigger cascading updates.
      • by babbage (61057)

        Or is it when the Debian people say "stable", they mean a stable feature set and not necessarily stable security-wise?

        I think that's precisely it.

        I just left a job where all the Linux machines were running Debian Stable [Woody], unless there was a specific requirement for something else (e.g. a commercial application that wouldn't run reliably on anything but RHEL).

        Everything was buggy as hell, but the admins were okay with this, because it was "stable". Desktop applications had thorougly well do

    • by Chmarr (18662) on Tuesday July 05, 2005 @06:09PM (#12989276)
      Well, it works for the OpenBSD people... OpenBSD is the most secure system out of the box because the box is really small, and it's hard to get it open :)

      My karma is now really, really shot.
      • True. :) But it should be said that if you go beyond the basic system and add packages, OpenBSD can suffer from the same problem - packages *do* get fixed when security holes are found, of course, but they're not generally taken as seriously as the base system.

        Of course, the fact that there *is* a base system that does not come in the form of packages (in the sense of pkg_addable ones, that is - the base system tarballs don't count as packages in that regard) is one thing that sets OpenBSD (and, from what
    • by arivanov (12034)
      That is not the problem. Problem is elsewhere.

      Redhat supports x86, x86_64, i64 and some power and zSeries stuff. Compared to that Debian supports Alpha, ARM, HP PA-RISC, Intel x86, Intel IA-64, Motorola 680x0, MIPS, MIPS (DEC), PowerPC, IBM S/390, SPARC. It also has the outrageously silly policy of trying to release updates for all of them at the same time.

      Frankly, all the "problematic" architectures for which there are build problems are "security through obscurity" by themselves. If an update for them i
      • Its not outrageously silly. It might appear to be to someone who only runs one or two, (which is not necessarily you), but it makes complete sense to someone who runs several of them. It means that Debian is Debian no matter what system you run it on. I wouldn't have to think, ok which systems have a patch for exploit A, and which don't, I would know for everything before I started anything.
        • by arivanov (12034)
          Nope.

          It is outrageously silly.

          Ever tried to write shellcode for Alpha? It was even thought to be impossible for more then 5 years until someone published a way to do some limited borderline cases in 2000.

          Ever tried to write shellcode for 680xx? Same as above, even harder due to the protection model vagaries.

          Basically these arches use a different protection model and instruction encoding from x86. Both of these make writing shellcode nearly impossible.

          So on, so fourth.
    • At this second, FreeBSD's ports collection has 13127 entries, which probably puts it close to Debian's equal by the time you weed out multiple versions of Debian packages. Is FreeBSD having the same problems, or are they handling the situation, or are they just ignoring it?
      • My impression is they just ignore it. But then, I'm just a noob.

        But their package compilation system looks a lot like:


        tar -zxf foo.tar.gz
        cd foo
        make
        make-install

        That doesn't seem like a distribution-maintained package at all.
        • But their package compilation system looks a lot like:

          They make quite a few binary packages available [freebsd.org].

          That doesn't seem like a distribution-maintained package at all.

          Is there a fundamental difference between providing a binary archive, and distributing the tools for users to automatically create exact copies of that archive?

          • Again, I'm new in BSD-land, but my impression is that if I install a bzflag package (a game), there's not some hard-working bsd guru out there pouring over the sources to bzflag, looking for buffer overruns. I have been known to get Debian security alerts for games from time to time, from which I infer there is some Debian guru pouring over the sources looking for security holes. Obviously, Debian is way to huge for even an infinate number of these gurus to get this right, so they're necessarily going to
        • by trezor (555230)

          More like:

          cd /usr/ports/typeofprogram/name
          make
          make install

          And after you install CVS to update your ports tree you get the newer versions. Granted, it's not releasing fixes for the old ones, but saying there is no consistent way of doing stuff in FreeBSD is just flat out wrong.

      • if you look at debian security announcements you'll see that thye have 112 security announcements made in this year

        That's one announcement every three days, more or less. And that's counting that those have been filed against the old debian stable (only more than 800 packages). With 14000, they're going to have more

        But freebsd security team just cares about the "core" system packages not about the 13000 ports. So it's not the same, but you get the idea: The work behing the debian security team is HUGE
      • by cperciva (102828) on Tuesday July 05, 2005 @07:43PM (#12989898) Homepage
        Is FreeBSD having the same problems, or are they handling the situation, or are they just ignoring it?

        The FreeBSD base system is supported quite well, although we have had occasional manpower problems (e.g., when one member of the security team is travelling around Japan on work, one member is writing his doctoral thesis, another member is job-hunting, et cetera).

        The FreeBSD ports tree is supported on a "best effort" basis -- we make no guarantees, but we do our best.
    • No, too many architectures.

      They won't release a security update until they have it working across all architectures.

      Given that some of them are for remarkably slow hardware, it can take a while to compile and test.

      Hence, debian security releases happen at the speed of the slowest.

      Not ideal really.

      The sudo hole was reported and fixed in openbsd about two weeks before debian. In gentoo and ubuntu about one week before debian.
  • hobbyist OS? (Score:2, Insightful)

    by OffTheLip (636691)
    Not to start a flamewar (well maybe a little) - OSS will need to meet the challenge of managing all of the little details of a widely acceted OS. Red Hat is grapling with that problem now with some suceess. Having what you believe to be a better widget is not enough.
  • Bits of News (Score:2, Interesting)

    by Masq666 (861213)
    I originally posted this on http://bitsofnews.com/ [bitsofnews.com] but decided to post it on Slashdot also. It's a bit sad though that Debian is struggling with it's security updates, Debian used to be a nice distro but i've changed to Suse myself due to the lack og updates.
  • So, if you've used Debian before and then migrated to something else, do tell. Is there anything that compares to apt-get? (no, urpmi is NOT it).
    • I use this [microsoft.com] and this [cygwin.com] and it works like a charm.
    • 'yum update' (for RPM-style distributions) works very nicely, thank you.

      However, while it does feel like a 'front end to rpm' much more than apt-get feels like a front end to dpkg... that's just fine by me. I LIKE things that are distinctly layered
    • Mandrake/Mandriva with urpmi.

      RPM is a technicaly better package manager than dpkg. With the sources list updated, there have been no dependancy hell problems. It automatically download and installs packages and thier dependancies. It works better than YUM, works better and quicker than portage, and is at least as good (many ways superior but only because a better maintained servers list) as apt-rpm.
    • I have used Debian since 2000 or so and have slowly been moving boxes to freebsd for the last 6 months or so. It was everything I loved in Debian, files are put in sane places, stable, not bleeding edge but current enough. It also had a good sized community that in a lot of way reminds me of debian. And going to your question it had a package management system that actualy works. Since freeBSD had come out with the 6-current series it even had a "Sid".
    • I'm also in the moved-to-Gentoo camp, although I also use FreeBSD in a lot of places (including several desktops). I guess I like the extra configurability of source-based systems over binary Linux distros.

      For example, Debian currently lets me choose between "openssh-client" version 4.1p1-4, or "ssh-krb5" version 3.8.1p1-8; I have to pick between a recent version or Kerberos support.

      I still like Debian and its derivatives, but I decided that it imposed constraints that I was not personally willing to

    • *BSD. (Score:3, Informative)

      by MrDomino (799876)

      All of the BSDs currently have excellent package-management systems that can elegantly handle both binary and source packages. pkgsrc in particular is a really nice system---further, it has the advantage of not being tied to one OS. Although it is developed primarily for NetBSD [netbsd.org], it can be used from any of the other BSDs, Linux, several Unices, and even Windows (with Internix, i.e. Windows Services for Unix [microsoft.com]).

      In fact, it's definitely worth checking NetBSD out; the 2.x line has been really interesting, and d

    • by Halvy (748070)

      i notice noone responded to your question *yet* so i'll give me .02 worth.

      nothing *compares*, but you have to compare apples with apples.

      and since debian is well, only debian, i can only add that Synaptic (graphical front end) for apt-get is alot easier to use when you want to install or change alot of programs.

      I also notice quite a few of the *other* distros are implementing apt-get/synaptic with their releases, in addition to whatever else they would normaly have as default (ie urpmi, Kpackage, et

  • Current issues (Score:3, Informative)

    by cortana (588495) <sam@robo[ ]org.uk ['ts.' in gap]> on Tuesday July 05, 2005 @06:00PM (#12989213) Homepage
    http://newraff.debian.org/~joeyh/stable-security.h tml [debian.org] is an incomplete list of issues currently affecting stable. It's not 100% correct; in addition to the provisos at the top of the page, it doesn't seem to know about recent updates such as this morning's Gaim update [debian.org].
  • I wonder, if unstable get's the "latest and greatest", so to speak, are there times that it gets security fixes before "stable"? The article mentions that Gentoo got a fix before Debian, presumably when it was fixed upstream. Did Debian unstable get the fix at the same time?
    • I don't know about recent issues, but for last year or even two years of Woody being stable version, there were many security problems in Woody which were resolved very slowly or not at all, while the unstable was usually fixed in reasonable time.

      Of course, unstable is what it says. You get new features, different behavior and even broken software all the time. Not very good thing in production enviroment. And right now there's some major changes going on in the unstable (C++ ABI and Xorg transition) and I
    • Yes, there are times when Unstable gets fixed faster than Stable. The way the whole Stable/Testing/Unstable thing works is that a package maintainer submits a package to Debian. It is placed in unstable. If it survives two weeks there, it is moved to testing. Eventually, there is a freeze and all of testing becomes stable. Now, if a bug is found in a testing package, a new package is submitted to Debian to replace it. So it ends up in Unstable for two weeks. Packages can be fast tracked from Unstable
  • by cperciva (102828) on Tuesday July 05, 2005 @06:13PM (#12989304) Homepage
    Woah! Wait a moment before you start flaming me on the basis of my subject line...

    The problem of providing security support is ill-suited to being solved by the traditional "mob of volunteers" approach which describes most open source development. When you're doing development, it doesn't matter if you have five people coding one week and nobody doing any coding the next week; but when it comes to dealing with a constant stream of security issues which are being reported (in particular, from upstream vendors), it is important to guarantee that there will be someone around to deal with them. When the entire security team consists of people who have other full-time jobs, it's impossible to make sure that someone will be around when they are needed.

    The job of "security officer" is really one which should be a job, not a role-played-by-a-volunteer. Go out and raise some money to pay for your security officer, so that he is able to always be available when he is needed, because if he needs to get some other job to support himself, he won't be around when you need him.
    • by bogie (31020) on Tuesday July 05, 2005 @08:29PM (#12990153) Journal
      "When the entire security team consists of people who have other full-time jobs, it's impossible to make sure that someone will be around when they are needed."

      Your wrongly basing your entire arguement on the idea that OSS programmer(s)=loner(s) with other "real" jobs. That is simply not the case for many OSS projects. Commercial OSS companies like Red Hat, Suse/Novell, et al are and have been the driving force in OSS for some time now. Look at any big distro, any major software project etc and at this point chances are they are being bankrolled and supported by commercial copanies that are paying people to work on them and deal with things like security issues. And if a popular project has a security flaw that an author won't address, and distros won't fix because its not part of their distro...well you know the deal, use the source luke.

      I see what your trying to say but again your arguement is flawed as "traditional" OSS development no longer means unpaid and non-commercial. I don't think that the people buying Red Hat linux and getting security support for years and years would share the same viewpoint. And I also don't think that commercial companies put more into security than OSS programmers do. History just doesn't show that.

      For version .002 for widget X that isn't widely used and gets abandoned for lack of interest and now has a security issue, how is that different than in the commercial world? At least with OSS someone/anyone can fix the problem. With commercial software you literally have to stop using the software because no fix will ever come.

      OSS is particulary well suited to dealing with security issues IMHO and the problems it has with security are more or less the same problems that commercial software makers face. Your floating down a well known river in Egypt if you think that in the commercial world all projects have people who are paid to soley to work on security.
  • Sorry to make yet another jab at the editors, but it needed to be done.
  • by atokata (872432) on Tuesday July 05, 2005 @07:44PM (#12989902)
    The article didn't go quite as in depth as I would have liked. Specifically, the Debian apt repositories have literally, and you may quote me, zillions* of packages. I'm fairly certain they have quite a few more than, say, Red Hat has binary packages in their repositories.

    Therefore, it would follow that if 4% of Debian packages had security vulnerabilities that would equate to a substantially greater number of packages than would the same 4% of Red Hat packages.

    The other important thing to keep in mind is that it's unlikely many users would install all zillion packages at one time.

    Finally, the article implies Debian and Red Hat are in competition. However, as literate geeks will know, Debian is the OS of "Software in the Public Interest" http://www.spi-inc.org/about [spi-inc.org] which is a non-profit entity. Therefore, while one could argue that Red Hat (a for-profit enterprise) and Debian are in competition for userbase, by no means are they in direct competition for 'business'.



    *Debian website says "over 15490." Which begs the question, how many more than 15490? 15491?
  • by joey (315) <joey@kitenet.net> on Wednesday July 06, 2005 @07:32AM (#12992824) Homepage
    I think it's indicative of the quality of this zdnet article that it attributes a page I maintain to Martin Schulze. More details in my blog entry, here:

    http://kitenet.net/~joey/blog/entry/secfud-2005-07 -06-11-28.html [kitenet.net]

Do not simplify the design of a program if a way can be found to make it complex and wonderful.

Working...