As many of you will already be aware, the OpenSSL 1.1.0 release intentionally
introduced significant API changes from the previous release[0][1]. In summary,
a large number of data structures that were previously publically visible have
been made opaque, with accessor functions being added in order to get and
set some of the fields within these now opaque structs. It is worth noting that
the use of opaque data structures is generally beneficial for libraries, since
changes can be made to these data structures without breaking the ABI. As 
such, the overall direction of these changes is largely reasonable.

However, while API change is generally necessary for progression, in this case
it would appear that there is NO transition plan and a complete disregard for
the impact that these changes would have on the overall open source ecosystem.

So far it seems that the only approach is to place the migration burden onto
each and every software project that uses OpenSSL, pushing significant code
changes to each project that migrates to OpenSSL 1.1, while maintaining
compatibility with the previous API (such as [2] and [3]). This is forcing
each project to provide their own backwards compatibility shims, which is
practically guaranteeing that there will be a proliferation of variable
quality implementations; it is almost a certainty that some of these will
contain bugs, potentially introducing security issues or memory leaks.

Due to a number of factors, software projects that make use of OpenSSL cannot
simply migrate to the 1.1 API and drop support for the 1.0 API - in most cases
they will need to continue to support both. Firstly, I am not aware of any
platform that has shipped a production release with OpenSSL 1.1 - any software
that supported OpenSSL 1.1 only, would effectively be unusable on every
platform for the time being. Secondly, the OpenSSL 1.0.2 release is supported
until the 31st of December 2019[4], while OpenSSL 1.1.0 is only supported
until the 31st of August 2018[4] - any LTS style release is clearly going to
consider shipping with 1.0.2 as a result.

Platforms that are attempting to ship with OpenSSL 1.1 are already
encountering significant challenges - for example, Debian currently has 257
packages (out of 518) that do not build against OpenSSL 1.1[5][6]. There are
also hidden gotchas for situations where different libraries are linked against
different OpenSSL versions and then share OpenSSL data structures between
them[7] - many of these problems will be difficult to detect since they only
fail at runtime.

But here's the thing - there are at least two options that OpenSSL had (and
still have) that would have avoided this situation and allowed for software
projects to make a smooth transition from the old API to the new API, without
every single project carrying backwards compatibility glue for at least the
next three years (and in reality, much longer).
I would implore the OpenSSL project to seriously reconsider their approach
to this API change and more importantly the associated migration, especially
keeping in mind what is going to be best for the overall ecosystem and not
just for the OpenSSL project. I would also ask software projects that make use
of OpenSSL to think carefully about how they approach this situation and in
particular consider how long they will need to carry compatibility code and
#ifs for.
Last but not least I would like to note that this is not a LibreSSL problem -
if we added all of the OpenSSL 1.1 accessors tomorrow, software written for
OpenSSL 1.0 or OpenSSL 1.1 would work seamlessly with LibreSSL. However,
software will still have to maintain compatibility with both of the OpenSSL
APIs, regardless of what we do.









Reply via email to