Mail archive

Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation

From: Kevin Chadwick <>
Date: Fri, 9 Feb 2018 11:38:55 +0000

On Thu, 8 Feb 2018 17:43:31 -0600

> Hello,
> On Thu, Feb 8, 2018 at 4:40 PM, Kevin Chadwick <>
> wrote:
> >> > You clearly do not know about the extra protections and
> >> > priviledge separation in LibreSSL!!!
> >>
> >> You must be talking about Pledge, which allows LibreSSL to declare
> >> what system calls it will and will not be using. Of course, Pledge
> >> is only available in OpenBSD.
> >
> > No, Pledge is not priviledge seperation or even close to it, though
> > it does benefit from it!
> >
> > Buffer overflows are far less dangerous with priviledge separation
> > deployed and no the way you compile Alpine will not accomplish
> > anything like proper priviledge seperation.
> Alpine has been using privilege separation for years where possible
> regardless of using LibreSSL or not. Privilege separation would not
> have prevented Heartbleed, as the unprivileged process would still
> require a copy of the X509 objects in order to perform cryptographic
> operations.

Cool, glad to hear it. My faith in Alpine is restored somewhat :)

That depends on the design which is also why I said compilation
wouldn't cut it.

> > _______________________________________________________________________
> >
> > As the OpenBSD 5.7 development effort comes to a close, so does the
> > LibreSSL 2.1.x branch. The next release will begin the 2.2.x
> > development branch.
> >
> > User-visible features:
> >
> > * Improvements to libtls:
> > - a new API for loading CA chains directly from memory instead
> > of a file, allowing verification with privilege separation in a
> > chroot without direct access to CA certificate files.
> > ________________________________________________________________________
> This type of design is not provided by libtls itself, but libtls
> provides the primitives for it. It is also possible to accomplish
> this design through the OpenSSL 1.0.1g API using a series of
> SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does
> internally), or just loading the certificate chain into X509 objects
> prior to calling fork(2).

And I am fairly sure the feature python wants is very simple and a lot
easier than that and not difficult security wise (oring etc.).

My question is, whether they have an agenda. Perhaps the build issues
here are different and not fully understood by me though.

I originally thought it was simply the following API call being desired
and I am under the impression LibreSSL will cater for it and it
wouldn't land in stable until 2019.

A much larger list has been shown with build issues that I cannot look
into so...

It was just the tone of the message that made me respond.


Received on Fri Feb 09 2018 - 11:38:55 UTC