X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 05BB4DC00A4 for ; Mon, 10 Nov 2014 23:07:17 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id m8so6499029obr.24 for ; Mon, 10 Nov 2014 15:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wY4MPbb7jefbQMwAfrT+z+eFpJYYqiE+54VkGwRvfAg=; b=SxFSmlQBYGlZkGji3hGvoJaYHsy1KtC9+bUP9ND19bckNfFye+7wWNcfXt46mXL/k7 aiJJ+qDe2xLcr4VEshY7/bF0+m25NQIwTnMpM4ljcql7WG+Jp3xVxZ6Svihron3c7nQs hL2xjMlNxOP2boOa9o8HlPJTFxCyVO2eZkc/Jh7DvXRosXcckQQmVJm1yDek7v1Pzmw+ LqNuco8F5j8tNJgIflZM7s7i/VpG3jxX/+hfj/vM3GnlMPrX7wG566ZF8b6bD1QHvCdy p0wDoH5vQgg9LVSPYGFt0pnLbDwJin9HfqbDnTVQn4hytZf+VxXh9L/vOY+DROzW/0oM icfQ== X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 X-Received: by 10.60.148.194 with SMTP id tu2mr4461391oeb.56.1415660837392; Mon, 10 Nov 2014 15:07:17 -0800 (PST) Received: by 10.202.129.70 with HTTP; Mon, 10 Nov 2014 15:07:17 -0800 (PST) In-Reply-To: References: <20141026092034.4491cfcc@vostro> Date: Mon, 10 Nov 2014 15:07:17 -0800 Message-ID: Subject: Re: [alpine-devel] LibreSSL - Thoughts on Integration From: Orion Miller To: William Pitcock Cc: Alpine-devel Content-Type: multipart/alternative; boundary=047d7b1636e355dbd20507893955 --047d7b1636e355dbd20507893955 Content-Type: text/plain; charset=UTF-8 > > 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 applications. 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 alternatives that I knew of. Thanks. --047d7b1636e355dbd20507893955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We evaluated the portable work done earlier in t= he year, we deemed it
too risky to switch for 3.0/3.1 cycles because of the bugs.=C2=A0 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.=C2=A0 Depending on the impact of that
divergence, we may choose to stick with OpenSSL for now until an
alternative comes along.

That's a bumme= r 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 applicat= ions.
Specifically ones that have been tested to work with LibreS= SL.=C2=A0

=C2=A0
=C2=A0 Just because OpenBSD makes something doesn't
mean it's the right choice for Alpine...
<= div>
I wasn't implying that. I was trying to say that Ope= nBSD has similar goals.
As a result it would be more likely that = the code produced for LibreSSL
would be more desirable for the Al= pine Linux community than code
produced for Ubuntu. I don't h= ave proof of this but I am making assumptions
from what I have ga= thered.

By 'better l= icense', 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.).=C2=A0 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).
=C2=A0
It is a common misconception that OpenSSL and LibreSSL are BSD
license; they are not.=C2=A0 They are under the same license as the
original Apache license (not Apache 2.0 license).=C2=A0 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.=C2=A0 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.<= br> Depending on the wording of those exception statements, they may or
may not apply to LibreSSL.=C2=A0 Thusly having a common framework under an<= br> appropriate license would allow us to avoid dealing with that
question.=C2=A0 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.
=C2=A0
Regarding BoringSSL: I don't really think it's a good plan for us,<= br> 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 t= hink and present all the other alternatives
that I knew of.
=

Thanks.
--047d7b1636e355dbd20507893955-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---