OpenSSL Shows Cost of 'Free'

The Heartbleed bug may be a media frenzy over a small, quickly patched bug, but it raises important questions about open-source software.

Free software may have become the crack cocaine of the high tech sector. The flaw in OpenSSL at the heart of the recent Heartbleed bug suggests it may be time to get into some sort of recovery program.

Is it time to reevaluate the real costs of free software, free Web services, and open-source code? Specifically, I wonder whether we need an industry consortium of paid members to vet and certify the security of widely used open-source software components.

I am no security expert. Decades ago college professors told me I didn't have a future as a software developer, either. So I am not taking a stand as a final authority, rather I seek to open discussion from experts on what are the next right steps.

A recent New York Times article highlighted the shoestring budget upon which OpenSSL is developed and maintained. It suggested the volunteer nature of open source code puts many projects in the same shabby boat.

As a user, I frequently go to free online web services to convert .wav to .mp3 files. Only recently have I seen one of them add a box to take contributions.

Like so many others, I regularly use Google search and maps and Facebook to communicate with friends and acquaintances. I know my information, my eyeballs, and my privacy are being sold every which way to more than pay for these free services.

As a journalist, I have seen the heavy price we pay for free news on the Internet. Most of the world's best newspapers and magazines struggle to survive while we swim in a sea of free news of questionable quality.

In the end I have questions I would like to hear this community address:

Is our open source code a similar sea of free software of questionable quality?

Was Heartbleed just a media blitz about a minor flaw, quickly patched, the sort of human error that comes from any system, open or closed?

Are today's software developers compensated in fair ways that reward their work?

In the end I wonder if the pendulum has swung too far in the direction of free, and it's about time to move back toward some center. Thanks in advance for taking time out to provide some free, but hopefully valuable, commentary.

It is not just Open sources developed with shoe strink budgets but also well paid softwares can have bugs. While we are talking about SSL, it may be worth while to note apple also had the ignonimity of a serious security flaw.

Coverity covers some OSS code vs. some Enterprise code (according to the report).

Clearly Coverity did not cover the OpenSSL code. Read the LibreSSL change log, it was a horror show of bad code.

I work for MS, and have on occasion written code for the OS. Just over 10 years ago Windows went through a massive and painful reset, where for the best part of a year the main activity was simply cleaning up the code base. Now, this was not just inspecting it and adding some comments (though that basic stuff happened). They built program verification tools in MS Research (you can look up the publications, Coverity probably learned from MSR who started on those tools in the 90s) and the coding standards included stringent annotations to enhance the capability of the automatic checking. The sort of mistake that LibreSSL is grumbling about simply can't be checked in to the source tree.

Now, I'm not claiming there are no bugs. Millions of lines of code are a complexity which can not be made perfect by humans, even with the aid of verification tools. There are modes of failure discovered which the tools do not yet check for. But there are commercial vendors who take this stuff very seriously, and have long ago built the tools and practices to avoid simple problems like buffer overruns or reading out of bounds, and many other risk factors.

OSS code has its advantages. We use it, and we contribute to it. But, inspection by human eyes is not all you need, and tools like Coverity are limited unless you are willing to strictly change your coding practices to improve automated reasoning and coverage. If you really want to build secure and critical code, deep investment in the practice and the tooling is a good idea.

I am not speaking for my employer here, just adding some perspective to this discussion about the nature of modern software engineering on proprietary software. I assume that many of our competitors have similar practice on critical code.

Go to Google and search for "Open source software qaulity" without the quotes.

Pick off the first article in the search referencing Coverity.

I'm loath to point a link to a competitor to EE Tmes directly on their pages. Just doesn't seem fair.

Coverity has been doing on-going research into OSS quality for quite awhile and their numbers match my personal experience in the industry. I've been a Linux user since nearly day 1 (Version 0.12) and have seen it grow into the true defacto Internet OS. This occurred through natural selection processes as much as anything. The original "Cathederal and Bazaar" article explained it best in my mind. Proprietary software is at a huge disadvantage because typically the people working on it simply do it for the love of it!

The one OSS project I've been personally affiliated with (Icarus Verilog) has been ongoing for something 14 years. The hand full of people that contribute to Icarus have been doing this with very little in the area of financial reward, but often because it solves their personal problems. They give a damn. So the results are merely born out by the Stats.

The corporate user is responsible for keeping the information safe so it is his responsibility to test. However this is no different if the software is proprietary, unless the vendor indemnifies the corporate user (not likely).