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 for two full-time OpenSSL developers so the organization can refurbish its 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.
Loading comments...
