Stop laying the blame for Heartbleed on open source

I’ve spent the last week considering the data and opinions concerning the Heartbleed bug that was found in the widely used OpenSSL cryptography library. OpenSSL is an open source project, so the occurrence of the bug has created an opportunity for many to decry the weakness of open source with shallow comments like: “The Heartbleed flaw, introduced in early 2012 in a minor adjustment to the OpenSSL protocol, highlights one of the failings of open source software development.”

I disagree with this profoundly. As Eric Raymond points out:

[O]ne thing conspicuously missing from the downshouting against OpenSSL is any pointer to a closed-source implementation that is known to have a lower defect rate over time.

[ 5 no-bull facts you need to know about Heartbleed | Track trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

Fortunately the kneejerk attacks on open source have been few, with most opinions tempered by the observation that OpenSSL is widely used because it is broadly the right solution for most programmers needing a TLS library. But a more thoughtful article in Wired still lists a series of potential criticisms of open source which could equally apply to proprietary code in the same roles.

The big difference? We would likely never know they applied. Closed development by unknown teams hidden behind corporate PR would seek to hide the truth, as well as prevent anyone from properly analyzing the issue once it became known. While commercial involvement is probably a key to reducing future risks, that does not equate to any preference for opaque proprietary behavior.

OpenSSL is probably the least-bad solution to the need for a crypto library. Recognizing that is not to deny problems in OpenSSL. As has been widely reported, the staffing levels of the OpenSSL project are woefully inadequate. One former project contributor explained to me that it’s complicated and unrewarding programming, and most people capable of doing it are also capable of getting a great job somewhere else. It would be reasonable to suggest that this staffing issue is actually a business model problem. While the project is busily fundraising, the actual problem is more fundamental, as the creator of an open source PDF facility explains:

I’ve said it before and I’ll say it again: Good engineers build great technology; great engineers also create a sustainable business model. Based on my 15 years of experience in open source, I know that it’s almost impossible to create a sustainable business model based on the Apache Software License [used by OpenSSL].

The sparse OpenSSL community has led some to assert that it’s the source of the problem, that what’s needed is proven community governance and strong community. While I agree with that both for OpenSSL and as a general concept, I believe it is a consequence of solving the problem and not the means. There’s no magic that will result in a team of smart crypto programmers suddenly appearing if there’s no business case for whoever pays them.

Security experts acknowledge that open source is the best model for crypto. Many eyes do indeed make bugs shallow, just so long as you can get them to look. So how do we drive improvement in the best-available model for creating security-critical infrastructure? Making Light says:

OSS culture doesn’t get called “socialistic,” but it’s self-organizing and anti-capitalist in its own way.

Open source is indeed not socialistic, but it’s also not anti-capitalist, since it depends on many developers independently responding to their own source of motivation to meet their own needs, but maximizing the benefit — lowering the cost and raising the innovation — by collaborating with their peers. The best way to drive improvement is to make it more rewarding, both financially and reputationally.

Tempting though it is to try to delegate the problem to Kickstarter and its like, that’s not done by throwing gifts at developers. The situation has prompted a variety of writers to claim Eric Raymond’s dictum — many eyes making all bugs shallow — is false. I disagree with them; I think Raymond has a great point, but the utopianism that sees volunteer communities as the answer stops short of understanding why people volunteer and volunteer the “many eyes.” Usually it’s because someone is paying them to.

That’s the problem we have to fix, both short-term and long-term. Short term, we need to get a team paid to audit OpenSSL again — it was last done in 2002. That could be crowdfunded as the Truecrypt audit was, or it could be bankrolled by some of the corporations who care about open source — a great opportunity to show their bona fides. This should be a one-off activity, in my view.

The question of the steps beyond this — procedural details, review boards, committees, and certifications and so on — has proved compelling to some. These will undoubtedly form part of a comprehensive solution and need medium-term attention. Since this work is so critical to so much of our infrastructure, we may well need to look back to the early days of the Internet and create some sort of independent, independently financed brain trust from which we can staff audits and reviews.

But I don’t think we have to sweat these details long term. We can safely leave that to the demand created when we identify the reason for the lack of incentive. The reason is OpenSSL is good, available, and free, for sure. But there’s a deeper issue: Using it has no consequences. In the inevitable case where a failure of code or concept is discovered, no one is blamed apart from the developers. Shouldn’t the commercial entities using the code have done some due diligence? Isn’t their lack of investment at least partly to blame? Software freedom delivers rights. What about responsibilities?

They should be employing developers to participate in this crucial project, so they have in-house skills in its close to half-million lines of code. We know who they are. Why haven’t they invested? I believe that’s the result of the ability of commercial software suppliers (of all kinds, proprietary and open source) to disclaim liability. Unlike pretty much any other kind of commercial venture, the deployers of software are able to disclaim all liability for harm caused by their code. Fix that, and the magic of market forces will fix everything else.

This is not to say the authors of the code should be personally liable. Open source projects don’t exist to create code for nonparticipants; they exist as the locus of collaboration for developers. It’s not reasonable to hold a project liable for its code quality (even if we should ask serious questions about code quality and governance). But the entities that deploy the code do have a responsibility. They need an incentive to pay developers, pay auditors, and promote quality and accountability. We’ll only get that when we fix the liability issue.

This is not a new thought. For example, in a 2008 report the European Union Agency for Network and Information Security said:

Networked systems, however, can cause harm to others, and the Commission should start to tackle this. A good starting point would be to require vendors to certify that their products are secure by default.

We recommend that the EU develop and enforce standards for network connected equipment to be secure by default.

Why has this not happened? I suspect the explanation concerns corporate lobbying by large proprietary software companies. It’s time for that to change, while we still have Heartbleed as a recent memory. Open source remains the best model for crypto (as well as most other software); we need to make sure software deployers realize that with great (software) freedom comes great responsibility.

This article, “Stop blaming open source for Heartbleed,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.