Date: Thu, 8 Feb 2018 19:22:07 +0000
From: Kevin Chadwick <m8il1ists@gmail.com>
To: alpine-dev <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system
 openssl implementation
Message-ID: <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk>
In-Reply-To: <CA+T2pCFi7iAqSxq500VYS=3a2GYTkF0akWhy6oVpL7B7O1N-Ew@mail.gmail.com>
References: <CA+T2pCGFeh30aEi43hAvJ3yoHBijABy_U62wfjhVmf3FmbNUUg@mail.gmail.com>
	<20180208180544.3ff19e66@mechanicum.chadwicks.me.uk>
	<CA+T2pCFi7iAqSxq500VYS=3a2GYTkF0akWhy6oVpL7B7O1N-Ew@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 8 Feb 2018 12:53:06 -0600


> Hello,
> 
> On Thu, Feb 8, 2018 at 12:05 PM, Kevin Chadwick <m8il1ists@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.

That is not the part that I was referring to, however as I
understand it this isn't an issue on OpenBSD or any constrained
embedded system that I develop??

> 
> > 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.
> 

That wasn't the point and I doubt you actually know that, but nvm.

> >> 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.
> 

Christian Heimes - 

The situation is, LibreSSL hasn't been compatible with any supported
OpenSSL version since 2017-01-01. The lack of compatibility with the
industry standard OpenSSL either means: drop LibreSSL or don't improve
security of Python's ssl module. 1 reply 0 retweets 1 like

Mark Espie -

you've got to realize that openssl deliberately broke compatibility
with previous versions precisely to try to stop libressl. we're talking
crypto, more fluffy interfaces are not necessarily better. Especially
when they allow people to create insecure crypto.

> >> 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.
> 

Is OpenSSL conformant, see above?

> > 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.
> 

You clearly do not know about the extra protections and priviledge
separation in LibreSSL!!!

> > 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.
> 

But packages like python have been demonstrated to run on the
constrained systems that they are designed for. OpenSSL is way too big.
I agree this is a Linux rather than Alpine issue, except for your desire
for more archs.

> > 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 priority?  
> 
> 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
> discussion.
> 

The point was that maybe Python should sort that out before removing
code here.

> 
> 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.

I disagree as explained at the time of their removal. You don't want
hairy/dangerous code in a security library.

I guess you think PAM is great too?



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---