On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists_at_gmail.com> wrote:
> 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.
I would argue that 32-bit systems not being able to validate
certificates from CAs who have expiry dates past year 2038 is a major
security problem. This is caused by the elimination of the TAI64N
date calculation code.
> 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.
Those CVEs were not avoided by removal of the functionality I listed
above. In fact, the removal of the functionality I listed above has
introduced security regressions.
>> 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.
This is not the case; LibreSSL have removed APIs that were part of the
OpenSSL 1.0.1g set. It is possible today, to have a program which
successfully compiles under OpenSSL 1.0.1g (e.g. the release at the
time of the LibreSSL fork) and fails to compile under LibreSSL.
Accordingly, they broke their promise.
>> 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
> you meant.
By proper, I mean an implementation that is conformant with the
OpenSSL 1.0.1g API, which is what was promised by LibreSSL.
> I believe the key protection improvements were/are better in LibreSSL
> and so the fix for heartbleed was properly done!
The protection improvements are the same: the custom memory management
code has been removed from both.
> 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
> of course)
mbedtls has never implemented the OpenSSL API. BoringSSL is not
appropriate as a system openssl implementation, it is mostly to
support Chromium and other Google products.
> 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
Any interpreter which has the ability to JIT (such as Python 3.6 with
an appropriate JIT module loaded) requires RWX. PaX will never allow
a page which has been marked PROT_WRITE to ever become PROT_EXEC. It
is what it is, and it's also unrelated to the LibreSSL vs OpenSSL 1.1
> (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 ;)
It is not Python that is the problem here; it is LibreSSL.
>> however retain libressl for packages which require it (for example,
>> ones using the new libtls APIs).
> A properly simple and secure API?
Sure, and that simple and secure API can be implemented using a
different TLS library other than LibreSSL, which still has plenty of
OpenSSL technical debt. It would make more sense from our perspective
to provide an alternative libtls that uses BearSSL or mbedTLS or
something else that is very small and already audited.
>> 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.
A stand for what? LibreSSL has removed support for things we want,
such as cryptographic accelerators and TAIN-based date calculations.
Neither of those functionality were removed for security reasons, but
instead because the OpenBSD developers did not want to deal with
maintaining them. I can understand their decision in doing so, but
that doesn't mean that the cost-benefit analysis works out favorably
for us anymore.
Received on Thu Feb 08 2018 - 12:53:06 UTC