Google has forked OpenSSL to create its own cryptography library dubbed BoringSSL – something that Mountain View reveals was done because maintaining the different patches Google created over years was getting difficult to manage over different code bases.
“Earlier this year, before Apple had too many goto fails and GnuTLS had too few, before everyone learnt that TLS heart-beat messages were a thing and that some bugs are really old, I started a tidy up of the OpenSSL code that we use at Google”, said Adam Langley, a widely respected cryptography engineer and Google employee.
Langley revealed that Google has been applying a series of patches on top of OpenSSL, quite a few which have already been merged into main OpenSSL repository, but added that many of these patches haven’t been included because either they don’t gel with OpenSSL’s guarantee of API and ABI stability or are too experimental in nature.
But as it turns out several Google products including Chrome and Android have started requiring these patches and things are becoming complex to the extent that keeping tabs on all these patches “across multiple code bases is getting to be too much”.
“So we’re switching models to one where we import changes from OpenSSL rather than rebasing on top of them. The result of that will start to appear in the Chromium repository soon and, over time, we hope to use it in Android and internally too”, revealed Langley.
The Google engineer revealed that this won’t change things w.r.t. to OpenSSL as they aren’t intending to compete with the open source product through BoringSSL and Google will still keep on pushing patches to OpenSSL and will continue funding both “the Core Infrastructure Initiative and the OpenBSD Foundation”.
It isn’t clear on how these forks will work or what are the points that will differentiate these forks from one another and help choose one over the other, but one thing is clear that heartbleed did get everyone on their toes resulting into LibreSSL followed by BoringSSL.
