Does Heartbleed Disprove 'Open Source is Safer'?: Page 2

An open community is supposed to make software development safer – or at least open source adherents have always claimed so.

WEBINAR: On-demand webcast

Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >

(Page 2 of 2)

In other words, the potential for a bug was detected and patched, but was by-passed by an engineering decision that favored efficiency over security. Perhaps, too, the wrapper was never examined closely because it was assumed to be trivial and to add nothing new. It had become an established part of the code that nobody was likely to modify. But, whatever the case, de Raadt concludes scathingly, "OpenSSL is not developed by a responsible team."

Assuming that de Raadt is right, then one take-away for FOSS is that all the eyes in the world cannot be counted on to catch basic design problems.

Taken together, Segglemann's and de Raadt's comments also suggest that assuming no special effort is needed to discover bugs is a mistake. Perhaps more attention needs to be paid to formal reviews and software testing than FOSS traditionally has managed. The fact that FOSS development often involves remote cooperation does not mean that log-in test or in-person testing sessions could not be added to many project's development cycle.

What Heartbleed proves is that FOSS needs at to examine the unexamined assumption it has held for years. Greg DeKoenigsberg, a vice president at Eucalyptus Systems, summed up the situation neatly on Facebook: "we don't put enough eyes in the right places, because we assume [bug-detection] will just happen because of open source pixie dust -- and now we're paying the price for it."

Redemption by Response

None of these comments are meant to suggest that the entire FOSS development model requires revision. If Heartbleed challenges Raymond's statement about enough eyes, the response to Heartbleed more than justifies it.

Knowledge of Heartbleed was apparently concealed for several weeks, but once it was announced, FOSS-based projects and sites quickly publicized it. A few hours more, and it was being patched. Individual users, of course, still need to change their passwords after sites apply their patches, but while some of the effects could linger for months, the FOSS response could not have been quicker or more responsible once the discovery was general knowledge.

By contrast, imagining a similar response from proprietary software is almost impossible. Based on past revelations of bugs and malware, a more likely reaction from proprietary software would have been to keep the problem secret while a patch was written and tested so that no one could exploit it. Meanwhile, millions of users would have remained exposed for weeks or months without realizing the danger.

Heartbleed is forcing another look at one of FOSS' basic beliefs, but the reaction to it is proving FOSS' ability to respond in a crisis. In the short run, FOSS will face ridicule because of its failure to detect Heartbleed earlier. Yet, already, the challenge to FOSS' basic beliefs is proving the ability of its developers to learn from their mistakes and improve.

Page 2 of 2

Previous Page
1 2

Tags: Linux, Open Source Programmers, Open Source Enterprise Software, Heartbleed

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.