Re: [alpine-devel] LibreSSL - Thoughts on Integration
> 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.
That's a bummer but thanks for taking a look. Even if LibreSSL can't become
a drop-in replacement would it be possible to use it for specific
Specifically ones that have been tested to work with LibreSSL.
> Just because OpenBSD makes something doesn't
> mean it's the right choice for Alpine...
I wasn't implying that. I was trying to say that OpenBSD has similar goals.
As a result it would be more likely that the code produced for LibreSSL
would be more desirable for the Alpine Linux community than code
produced for Ubuntu. I don't have proof of this but I am making assumptions
from what I have gathered.
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.
Oh okay. Thanks for clearing that up for me.
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 completely agree. Just was trying to think and present all the other
that I knew of.
Received on Mon Nov 10 2014 - 15:07:17 UTC