As developers continue heir struggles to fix the vulnerabilities within OpenSSL’s crypto library, Google has announced yet another fork of the project based on its own version of the code, amusingly dubbed BoringSSL.
Previously, Google added patches on top of each new OpenSSL release, essentially building its own hacked version of OpenSSL for use with Chrome, Android, and other Google tools. As code bases have proliferated, the process of tracking and applying all those patches has swelled in complexity. BoringSSL is the beginning of an attempt to unify Google’s code into a single, consistent library that can be shared across many projects.
“We have used a number of patches on top of OpenSSL for many years. Some of them have been accepted into the main OpenSSL repository, but many of them don’t mesh with OpenSSL’s guarantee of API and ABI stability and many of them are a little too experimental,” Google software engineer Adam Langley wrote in a blog post.
The new approach is to import changes from OpenSSL rather than to rebase code on top of them. “We are not aiming to replace OpenSSL as an open-source project. We will still be sending bug fixes when we find them and we will be importing changes from upstream,” Langley wrote.
Neither does the new project mean Google will drop its commitment to funding OpenBSD or the Core Infrastructure Initiative. OpenBSD is the body responsible for creating an earlier fork of OpenSSL called LibreSSL that came out just after the Heartbleed bug was discovered. The two projects will run side-by-side, and should both be able to import each other’s changes.
“We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed,” Langley added.
Theo de Raadt, the Founder and Leader of OpenBSD, welcomed BoringSSL.
“Their priority is on safety, not on ABI compatibility. Just like us,” de Raadt wrote in a blog post. “Over time, I suspect Google’s version will also become ‘reduced API’, since they require less legacy application support. That may give LibReSSL the opportunity to head in the same direction, if the applications are willing.”
De Raadt added that his foundation was close to finishing work on a portable version of LibreSSL that could work on Linux with only minor changes.
“Please stop believing rumors that we’ve made it hard to port! The entire world went to POSIX, and that’s all this code needs to support,” he said.