As many of you will already be aware, the OpenSSL 1.1.0 release intentionally introduced significant API changes from the previous release. 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  and ). 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, while OpenSSL 1.1.0 is only supported until the 31st of August 2018 - 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. There are also hidden gotchas for situations where different libraries are linked against different OpenSSL versions and then share OpenSSL data structures between them - 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.  https://wiki.openssl.org/index.php/1.1_API_Changes  https://abi-laboratory.pro/tracker/timeline/openssl/  https://github.com/php/php-src/commit/2ecce94756bebda9eca3084b586f5bc821174c50  https://github.com/openssh/openssh-portable/pull/48/files  https://www.openssl.org/policies/releasestrat.html  https://wiki.debian.org/OpenSSL-1.1  https://breakpoint.cc/openssl-trans/html/openssl.html  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018