On Thu, 8 Feb 2018 11:23:26 -0600
> 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.
This is a strange take on the situation to say the least.
Apis were dropped for good reasons and they have committed to
implementing new API components that seem sensible and are most
desired. However the primary goal is security not functionality and if
anything you could argue that OpenSSL is still way too complex to be
fit for purpose.
Multiple CVEs have been avoided by LibreSSL already.
> libressl promised to retain compatibility with 1.0.1g APIs, but has
> failed to do so.
I am not clear on the versions but I do know that they promised to be a
replacement at the time and whilst I am not really involved I have seen
comments that OpenSSL seem to be purposefully causing issues.
> As such, there is an increasing workload to keep
> packages compatible with libressl as it evolves. 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
Do you have a list of packages at all?
proper!?!? I guess LibreSSL has less resources and hope that is what
I believe the key protection improvements were/are better in LibreSSL
and so the fix for heartbleed was properly done!
I understand your workload point and that Alpine is far from in
control over this but I don't like how this mail has been written and
wonder what environment caused that? Also, there are other libraries
like mbedtls and boring ssl, aren't these packages breaking
compatibility with them and reducing their scope? (Not an alpine issue
So maybe the packages like Python have an agenda or should slow down?
Python could also remove RWX memory requirements by default as a higher
(Python, saying they want to remove existing code for more security
(would it be compiled) but that the existing code is secure). Have they
audited the OpenSSL code themselves? I understand the joy of code
deletion however ;)
> however retain libressl for packages which require it (for example,
> ones using the new libtls APIs).
A properly simple and secure API?
> If there is no objection to this proposed change, I intend to do the
> swap next week.
No objection, just not impressed. Alpine could make a stand but what
difference would it make.
Received on Thu Feb 08 2018 - 18:05:44 UTC