On 02/08/18 11:23, William Pitcock wrote:
> openssl 1.1 has a different situation: Akamai and the Core
> Infrastructure Initiative have come together to sponsor development
> and maintenance of openssl since we switched, which means that there's
> higher quality maintenance occuring now.
This is good to hear, I didn't know about Akamai's involvement.
> They are also working on a
> relicensing process, much like the libressl guys are doing, which has
> a larger scope.
That would be a boon; I wish them all the best in their efforts.
> Meanwhile, the libressl guys have been removing
> functionality we depend on, such as support for hardware accelerators
> (ENGINE apis), switching from 64-bit TAIN date calculations to time_t
> (because time_t is good enough on OpenBSD) and dropping openssl 1.0.1
> APIs they see as unsuitable.
> libressl promised to retain compatibility with 1.0.1g APIs, but has
> failed to do so. As such, there is an increasing workload to keep
> packages compatible with libressl as it evolves.
These have all caused a number of problems trying to run certain
packages on Alpine. For example, since python -dev requires
libressl-dev, you can't build Python packages that require OpenSSL. Not
to mention the fact that LibreSSL just plain doesn't work on Adélie's
32-bit PowerPC and x86 ports.
> Therefore, it is
> obviously not truly a suitable provider for the openssl package, and
> we should switch back to proper openssl as the default. We will
> however retain libressl for packages which require it (for example,
> ones using the new libtls APIs).
> : https://license.openssl.org/
One question I do have is: is there a way to disable the OpenSSL
compatibility in LibreSSL? It would be good for packages that require
LibreSSL (libressl-dev) to be buildable even if openssl-dev is installed
(preventing something like the above Python situation).
A. Wilcox (awilfox)
Project Lead, Adélie Linux
Received on Thu Feb 08 2018 - 12:09:38 UTC