In case you haven’t been paying attention, in recent months a number of serious vulnerabilities were found in the OpenSSL library, including the Heartbleed vulnerability. OpenSSL is used by a huge number of online service providers and sites to encrypt their connection to users and protect sensitive data. It’s a critical part of the Internet’s security infrastructure, and vulnerabilities can degrade trust in the online economy.
OpenSSL is an open source library, released under the GPL, which means that anyone with the inclination can take the code and do with it as they will provided they offer the same rights over any changes they make. There are two basic ways a developer can contribute to an open source application or library. They can contribute code to the project itself, or they can take that project’s code and start a brand new version — known as forking.
The ability to fork is a key component of the open source philosophy, but it’s not without drawbacks.
Developers with the time, expertise, and inclination to contribute to a project of OpenSSL’s complexity are thin on the ground. If all of them contributed to OpenSSL, it would likely be rapidly improved. But now we have three teams of developers working on three versions. There will be much duplication of effort, even though Google has promised that it will contribute its work back to the OpenSSL project.
As we discussed in a recent article, in an effort to prevent further Heartbleed scenarios from occurring, the Core Infrastructure Initiative was launched, with the aim of funding projects like OpenSSL to ensure that they have sufficient funds to support development and auditing. Google is a key contributor to the CII, but apparently feels that spreading its bets with a fork is also wise. The name BoringSSL is indicative of its purpose — Google doesn’t want any more surprises.
It appears Google’s fork is also motivated by its own internal requirements. The company currently applies dozens of patches to OpenSSL in order to modify it to better suit Google’s requirements. That’s a significant burden and one that has to be repeated whenever a new version of OpenSSL is released. By bringing development in house, Google create a predictable encryption library over which they exert control. They don’t have to ride out the vicissitudes of the collaborative development process.
The fundamental question is whether a diversion of resources away from OpenSSL and towards BoringSSL, LibreSSL, and others is the optimal path. What do you think? Should the community have gone all in on OpenSSL or are new competing projects the best way to ensure we don’t see another Heartbleed?
Image: Flickr/Salvatore G2