Slashdot Mirror


How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

jammag writes: "Heartbleed has dealt a blow to the image of free and open source software. In the self-mythology of FOSS, bugs like Heartbleed aren't supposed to happen when the source code is freely available and being worked with daily. As Eric Raymond famously said, 'given enough eyeballs, all bugs are shallow.' Many users of proprietary software, tired of FOSS's continual claims of superior security, welcome the idea that Heartbleed has punctured FOSS's pretensions. But is that what has happened?"

16 of 582 comments (clear)

  1. Wat? by Anonymous Coward · · Score: 5, Insightful

    In the self-mythology of FOSS, bugs like Heartbleed aren't supposed to happen when the source code is freely available and being worked with daily.

    False. Bugs can and do happen. However, what can also happen with open source software is that entities other than the group working on the project can find bugs. In this case, Google found the bug. If the source were not open, maybe it would have never been officially recognized and fixed.

    1. Re:Wat? by tysonedwards · · Score: 5, Interesting

      It is a double edged sword. Because one can see the code, there is visibility into the process. Because OpenSSL is such a common tool and is arguably vital to the function of the Internet as we know it, this sort of a bug really is one of those "worst case scenarios" PR wise, as opposed to being cleanly swept under the rug as is possible in the case of many Closed Source 0-day vulnerabilities.

      The problem here is that people have been using the argument that Open Source is better because these issues can't happen "because" of the visibility. And the argument "Open Source is inherently safer" has been very heavily damaged by Heartbleed and now ranks up there with "Macs don't get viruses" and "Women are worse drivers".

      If this happened in Microsoft, Adobe or Oracle Land this would be "yet another 0-day" and largely ignored by the public. Because it is in an area with such a vocal group of people spouting "Impenetrable" for decades, it all of the sudden becomes quite newsworthy in a way that "yet-another-remote-code-execution-with-privilege-escalation-in-Acrobat-Reader" vulnerability doesn't.

      And if you doubt any of this for a moment, have you ever heard the name of the developer who was at fault for introducing a bug into Flash on the local news? Now did you hear the name "Robin Seggelmann" in connection to Heartbleed?

      --
      Thirty four characters live here.
    2. Re:Wat? by jc42 · · Score: 5, Insightful

      No, just no. No one with any sort of a clue ever argued these issues cannot happen with Free Software.

      No, they haven't made that claim in so many words. But they've sure as hell implied it for years now. That's the whole line of thought that Raymond's statement (quoted in TFS) is based on.

      Huh? The quote is "given enough eyeballs, all bugs are shallow." That's a clear admission that open software, like all other software, contains bugs; that's why you want the many eyeballs. Any claim otherwise is a symptom of not understanding plain English. Eric's whole point was that the bugs in open software will be found and fixed faster than the bugs in other software, due to the population of interested people who will study it, looking for the bugs. Nothing in that quote implies (to anyone with reasonable understanding of English and basic logic) that open software doesn't have bugs. I expect Eric would just chuckle at the very idea of software without bugs.

      (Actually, someone near him should ask him. Tell us whether he chuckles, or snickers, or just gets a sad look on his face. Or maybe he'll say "Well, there is a conjecture that bug-free software exists, but in has never been observed in the field by reliable observers." ;-)

      A much more useful conclusion from this story (if you're serious about computer security) is that this bug has been found and fixed in OpenSSL, but with its proprietary competitors, we have no way of knowing what horrible exploits they may be hiding. And you'd be a dummy to think they don't have exploits; every chunk of security-related software has exploits. The meaningful question is whether they can be found and fixed by the people using the software. If not, you'd be a fool to use that software.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
  2. Mr Fixit by frisket · · Score: 5, Insightful
    All that has happened is that FLOSS has been shown to react faster to security revelations than closed or proprietary softwarre.

    That's fine with me.

  3. Even a bestselling novel can have a typo by sandytaru · · Score: 5, Insightful

    We're surrounded by tiny errors in the world. Heck, they're even built into our DNA. The vast majority of tiny little errors do no harm, and we don't notice them. We gloss over them, like a typo in a book. It's just that every once in a while, a tiny little error can occur that snowballs into something much greater. Like cancer. Or a massive, accidental security leak.

    More eyeballs usually do make bugs more shallow, but only if the eyes know what to look for.

    --
    Occasionally living proof of the Ballmer peak.
  4. Original premise is false by bazmail · · Score: 5, Insightful

    Many eyeballs may make bugs shallower, but those many eyeballs don't really exist. Source availability does not translate to many people examining that source. People, myself included, may like to build to install packages but that's it.

    What we need are intelligent bots to constantly trawl source repositories looking for bugs. People just don't have the time any more.

  5. Overstating the case by kurisuto · · Score: 5, Insightful

    I don't think anyone claims that open-source software won't ever have security issues. The claim is that the open-source model tends to find and correct the flaws more effectively than the closed-source model, and that the soundness of the resulting product tends to be better on average.

    One case does not disprove that. The key words there are "tends" and "on average".

  6. Uh, what? by Zontar+The+Mindless · · Score: 5, Insightful

    Q: How Does Heartbleed Alter the 'Open Source Is Safer' Discussion?

    A: It doesn't. OSS is purported to be a *better* software development methodology. "Better" != "perfect". TFS is a troll.

    --
    Il n'y a pas de Planet B.
  7. This bug was found in OpenSSL because it was open by Anonymous Coward · · Score: 5, Insightful

    What hasn't been found in closed source software because it is too inconvenient to look?

  8. Re:Open source was never safer by Anonymous Coward · · Score: 5, Insightful

    I don't know, Microsoft got caught about being able to waltz through the password check with full spaces, which is slightly worse than forgetting to place a character limit back onto something. Admittedly the stakes are not the same, but you can check it, and enough do that it works.
    It's safer in terms of checking for back doors, sloppy coding anyone can do.

  9. Re:Open source was never safer by LordThyGod · · Score: 5, Insightful

    Closed source was always safer.

    One word for you: Microsoft. Maybe two: Adobe.

  10. Re:we don't know what happened AT ALL by Cid+Highwind · · Score: 5, Informative

    "Yes, we can trace the changelogs in the software & note who was checking the changes and missed them, but that all can be circumvented."

    Actually it can't. That's kind of the point of git.

    "The fact is we don't know if Heartbleed was an honest mistake or not...we don't know who knew and when..."

    We do know who and what and when, because the person who wrote it and the person who signed off on it have commented publicly about the bug.

    Maybe you're thinking of Apple's "goto fail" SSL exploit where we really don't know who or what or when and probably never will because it's not likely Apple is going to release their RCS logs.

    --
    0 1 - just my two bits
  11. Re:Open source was never safer by erroneus · · Score: 5, Interesting

    Closed source is hazardous in many ways. Along with being more frequently targeted, the NSA revelations showed that Microsoft worked with the NSA when deciding how quickly to close some holes. Another hazard is the threat of being attacked and/or sued by companies whose products were found to have problems.

    No question the heartbleed thing is a huge and embarassing problem. But you know? It's actually kind of hard to count the number of high-profile vulnerabilities in F/OSS software as not a whole lot come to mind. On the other hand, the list is enormous for closed source from large companies... also hard to count but for another reason.

    It does highlight one important thing about F/OSS, though. Just because a project has enjoyed a long, stable and wide deployment, code auditing and other security practices are pretty important and just because it's a very mature project doesn't mean something hasn't been there a long time and had simply gone unnoticed for a long, long time. People need wakeup calls from time to time and F/OSS developers can be among the worst when it comes to their attitudes about their territories and kingdoms. (I can't ever pass up the opportunity to complain about GIMP and GNOME... jackasses, the lot of them.)

  12. Re:Leaked by codenomicon by Thiarna · · Score: 5, Interesting

    I had to dig for direct connections between Codenomicon and Microsoft, but the chairman of the board seems a fairly strong link. The way Codenomicon have behaved in this has seemed reckless, I've never seen a bug so heavily marketed. The stats floating around initially seem to be way off the mark - to begin with quotes were of 66% of web servers being affected, later revised to 17% running affected versions. Both these numbers look too round to be anything other than made up.

  13. Why is Raymond's claim theoretically sound? by Anonymous+Brave+Guy · · Score: 5, Interesting

    Raymond's proposition is theoretically sound

    No, it isn't. It's nonsense and it always has been.

    There is plenty of evidence for the effectiveness of good code reviews, but most of it shows rapidly diminishing returns with the number of reviewers. You get much of the benefit from having even one or two additional people read over something. By the time you've had more than four or five people take a look, the difference in effectiveness from adding more barely even registers, unless one of the additional reviewers has some sort of unique perspective or expertise that makes them not like the others.

    Given that almost every major FOSS system software project has had its share of security bugs, there is really very little evidence to support Raymond's claim at all. It's not like it has ever been taken seriously outside the FOSS fan club, but there are a lot of FOSS fans on Slashdot, and so plenty of comments (and positive moderations) reinforce the groupthink as though it's some inherent truth.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    1. Re:Why is Raymond's claim theoretically sound? by TsuruchiBrian · · Score: 5, Insightful

      There is plenty of evidence for the effectiveness of good code reviews, but most of it shows rapidly diminishing returns with the number of reviewers.

      To me this is an argument *for* open source software. It *takes* LOTS of eyes to catch bugs, *because* there is diminishing returns by adding more code reviewers. It is only by having hundred or thousands of them that you can hope to catch those ones that would otherwise go unnoticed.

      By the time you've had more than four or five people take a look, the difference in effectiveness from adding more barely even registers, unless one of the additional reviewers has some sort of unique perspective or expertise that makes them not like the others.

      And one easy way to have a diverse group of code reviewers is to have a lot of them.

      Given that almost every major FOSS system software project has had its share of security bugs, there is really very little evidence to support Raymond's claim at all.

      Every piece of software of any reasonable size has security bugs. The fact that we know about them is because someone found them, which is exactly what is supposed to happen.