Subject: [alpine-devel] LibreSSL - Thoughts on Integration

From: systmkor <[email-masked]>
Date: Sat, 25 Oct 2014 21:02:39 -0700

Is there any plans on making LibreSSL a package, alternative install to OpenSSL, or becoming the default instead of OpenSSL? What do you guys think and why?

---

From: Timo Teras <[email-masked]>
Date: Sun, 26 Oct 2014 09:20:34 +0200

On Sat, 25 Oct 2014 21:02:39 -0700
systmkor <[email-masked]> wrote:

> Is there any plans on making LibreSSL a package, alternative install
> to OpenSSL, or becoming the default instead of OpenSSL? What do you
> guys think and why?

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.

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.

I think we'll reconsider starting using libressl after next stable
branching of Alpine (which is due in few weeks).

/Timo

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: systmkor <[email-masked]>
Date: Sun, 26 Oct 2014 13:10:20 -0700

> 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

> 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. 

> branching of Alpine (which is due in few weeks).

Should I create an issue for this on redmine tracker?

---

From: William Pitcock <[email-masked]>
Date: Sat, 8 Nov 2014 12:26:17 -0600

Hello,

> 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...

> 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...

> 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

---

---

From: Orion Miller <[email-masked]>
Date: Mon, 10 Nov 2014 15:07:17 -0800

> 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

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.

> us interested in going this direction.

Oh okay. Thanks for clearing that up for me.

> I completely agree. Just was trying to think and present all the other
alternatives
that I knew of.

Thanks.

---

From: Chris Spillane <[email-masked]>
Date: Mon, 27 Oct 2014 15:06:45 +0000

well, since nobody has mentioned it yet I'm going to throw this one into
the mix:

How about PolarSSL?

https://polarssl.org

-- 
Chris Spillane

---

From: IT Developer <[email-masked]>
Date: Mon, 27 Oct 2014 16:04:49 +0000

It's also possible to build OpenVPN with PolarSSL:

https://community.openvpn.net/openvpn/wiki/UsingPolarSSL

this is the version used by the Dutch government
<http://www.yro.slashdot.org/story/11/11/24/1827251/dutch-government-officially-trusts-openvpn-nl>.

On 10/27/2014 03:06 PM, Chris Spillane wrote:
> well, since nobody has mentioned it yet I'm going to throw this one
> into the mix:
>
> How about PolarSSL?
>
> https://polarssl.org
>
> On 26 October 2014 20:10, systmkor <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     official repository for it.
>     https://github.com/libressl-portable/portable
>
>

---

From: Daniel Cegiełka <[email-masked]>
Date: Mon, 27 Oct 2014 18:31:17 +0100

2014-10-27 17:04 GMT+01:00 IT Developer <[email-masked]>:
> this is the version used by the Dutch government.
>
>
>
> well, since nobody has mentioned it yet I'm going to throw this one into the
> mix:
>
> How about PolarSSL?
>
> https://polarssl.org

Correct me, but in PolarSSL there is no support for ChaCha20 cipher
and the Poly1305 MAC, which are very fast and secure.

http://cr.yp.to/chacha.html
http://cr.yp.to/mac.html

Support for Curve25519?

https://polarssl.org/discussions/bug-report-issues/support-for-curve25519

Daniel

---

---

From: Isaac Dunham <[email-masked]>
Date: Mon, 27 Oct 2014 10:37:01 -0700

> well, since nobody has mentioned it yet I'm going to throw this one into

Can it build wpa_supplicant/hostapd, svn, sylpheed, claws-mail, mutt, alpine,
libssh/libssh2, krb5, lynx, elinks, git/cgit, tarsnap, and so on?

~/aports$ grep -l openssl-dev */*/APKBUILD |wc -l
220

I'd go for libressl, since it would not be trivial to get 220 pacckages
to work with a new API (though I'd assume that a few already support it,
and some might be easy to port.)

Thanks,
Isaac Dunham

---

---

From: systmkor <[email-masked]>
Date: Mon, 27 Oct 2014 11:00:47 -0700

> and some might be easy to port.)

While I do think PolarSSL should be examined, I agree with Isaac that LibreSSL
is the way to go (at least for now). The OpenBSD community is eccentric but
they genuinely are interested in producing robust and secure code.

I would say the more longterm goal as being able to have multiple SSL libraries
on the system that are not in conflict with each other. Enabling users to run
which ever SSL library they would like for a specific package/application/server.