Google unveils independent “fork” of OpenSSL called “BoringSSL”

Google is releasing its own independently developed “fork” of OpenSSL, the widely used cryptography library that came to international attention following the Heartbleed vulnerability that threatened hundreds of thousands of websites with catastrophic attacks.

The unveiling of BoringSSL, as the Google fork has been dubbed, means there will be three separate versions of OpenSSL, which is best known for implementing the secure socket layer and transport layer security protocols on an estimated 500,000 websites. Developers of the OpenBSD operating system took the wraps off LibreSSL a few weeks after the surfacing of Heartbleed. Google is taking pains to ensure BoringSSL won’t unnecessarily compete or interfere with either of those independent projects. Among other things, the company will continue to back the Core Infrastructure Initiative, which is providing $100,000 in funding to OpenSSL developers so they can refurbish their badly aging code base.
“But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us,” Adam Langley, a widely respected cryptography engineer and Google employee, wrote in a blog post introducing BoringSSL. “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.”

While it wasn’t immediately clear how the forks will function—or when it makes sense to use one over another—the following exchange from this Hackernews forum may provide some clues.

matteotom
So from what I understand, Google has a bunch of OpenSSL patches they use. They used to re-apply those patches to each new OpenSSL release, but now they’re going to keep their own branch (BoringSSL) and pull and merge changes from OpenSSL?

What are the costs/benifits of one method over the other?

agl
I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it.

However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.

tedunangst
Fewer surprises. You don’t wake up one day and discover that TLS heartbeats have appeared in your library as a result of previous upgrades. Every upstream change has to be reviewed because that’s the only way it gets in. Also, local changes are much less likely to be lost as a result of merge conflicts.

The downside is that you may miss some upstream changes that you do care about.

borando
Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I’m looking forward to a healthy TLS ecosystem.
The AGL participant, for the record, is Google’s Langley.

In Friday’s blog post, Langley characterized BoringSSL as a much lighter-weight version of OpenSSL that strips out many of the application programing interfaces (APIs) and application binary interfaces (ABIs) found in the latter.

“There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project,” he wrote. “We will still be sending them bug fixes when we find them and we will be importing changes from upstream. Also, we will still be funding the Core Infrastructure Initiative and the OpenBSD Foundation.”

Matthew Green, a Johns Hopkins University professor specializing in cryptography, was also optimistic about the unveiling of BoringSSL despite the prospects it creates more competition for a finite amount of funding and mindshare.

“I’m sure Adam’s fork is good,” he told Ars. “I’m sure he’s gone through and done exactly what should be done to OpenSSL, so he may be ahead of LibreSSL in a lot of ways.”

source: arstechnica