Precedence: list
MIME-Version: 1.0
In-Reply-To: <AD1CAE38-56FC-4EFC-8FE1-373D1BD689DA@gmail.com>
References: <AA12821A-4861-49EA-BF61-0A7F64AA0896@gmail.com>
	<20141026092034.4491cfcc@vostro>
	<AD1CAE38-56FC-4EFC-8FE1-373D1BD689DA@gmail.com>
Date: Sat, 8 Nov 2014 12:26:17 -0600
Message-ID: <CA+T2pCEywNiR9w-FyYXs1GpePguEWaJ1+aL5Lay=ghp1VyR92A@mail.gmail.com>
Subject: Re: [alpine-devel] LibreSSL - Thoughts on Integration
From: William Pitcock <nenolod@dereferenced.org>
To: systmkor <systmkor@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Content-Type: text/plain; charset=UTF-8

Hello,

On Sun, Oct 26, 2014 at 3:10 PM, systmkor <systmkor@gmail.com> wrote:
>
>> We discussed this when libressl was published, and decided to wait at
>> least a little bit because the initial versions had some bugs, and the
>> portable version was not available.
>
>
> It appears that the portable version is somewhat stable now. I think this is the
> official repository for it. https://github.com/libressl-portable/portable
>

We evaluated the portable work done earlier in the year, we deemed it
too risky to switch for 3.0/3.1 cycles because of the bugs.  There are
other concerns, specifically, it is not presently known whether or not
LibreSSL is actually api-compatible with OpenSSL anymore, because they
have diverged in some areas.  Depending on the impact of that
divergence, we may choose to stick with OpenSSL for now until an
alternative comes along.  Just because OpenBSD makes something doesn't
mean it's the right choice for Alpine...

>> There was also discussion on picking up some other proven crypto
>> library with better license, and just write openssl api layer for it.
>> But this is a lot bigger job and has not progressed since.
>
> While I am not a huge fan of the BSD license but I do think it
> has its appropriate uses. There is also BoringSSL at
> https://boringssl.googlesource.com/ which could eventually become
> another alternate version.

By 'better license', we mean that we would want a cryptographic
framework under a non-copyleft, ideally BSD-style license without the
GPL-incompatible advertising clauses (i.e. ISC license, 2-clause BSD,
etc.).  In other words, any cryptographic framework which is under
license terms worse than the present status quo would likely be
rejected, i.e. we would not want a GPL cryptography framework
(although LGPL would be fine).

It is a common misconception that OpenSSL and LibreSSL are BSD
license; they are not.  They are under the same license as the
original Apache license (not Apache 2.0 license).  The advertising
clause in the Apache license (based on the 4-clause BSD license) means
that the license is GPL-incompatible, which is a source of major legal
problems with OpenSSL/LibreSSL.  The reason why we would want a
non-copyleft license is so that we have the broadest possible
licensing compatibility with other packages in the Alpine system.

Another legal problem is that at present, many GPL packages have to
ship an "OpenSSL license exception" statement alongside the GPL.
Depending on the wording of those exception statements, they may or
may not apply to LibreSSL.  Thusly having a common framework under an
appropriate license would allow us to avoid dealing with that
question.  This concern as well as the ability to have a single
unified point for bug fixes in the cryptography stack, is what makes
us interested in going this direction.

Regarding BoringSSL: I don't really think it's a good plan for us,
it's highly modified mostly for the uses of Chrome/Chromium, and the
idea of putting our base cryptographic framework under the control of
Google, Inc. does not really appeal to me either... in fact, it makes
me want to cringe...

>> I think we'll reconsider starting using libressl after next stable
>> branching of Alpine (which is due in few weeks).
>
> Should I create an issue for this on redmine tracker?

I have no opinion either way on this; we will discuss it irregardless
of whether there is a tracker item.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---