~alpine/devel

9 8

[alpine-devel] LibreSSL - Thoughts on Integration

Details
Message ID
<AA12821A-4861-49EA-BF61-0A7F64AA0896@gmail.com>
Sender timestamp
1414296159
DKIM signature
missing
Download raw message
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?
Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20141026092034.4491cfcc@vostro>
In-Reply-To
<AA12821A-4861-49EA-BF61-0A7F64AA0896@gmail.com> (view parent)
Sender timestamp
1414308034
DKIM signature
missing
Download raw message
On Sat, 25 Oct 2014 21:02:39 -0700
systmkor <systmkor@gmail.com> 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:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<AD1CAE38-56FC-4EFC-8FE1-373D1BD689DA@gmail.com>
In-Reply-To
<20141026092034.4491cfcc@vostro> (view parent)
Sender timestamp
1414354220
DKIM signature
missing
Download raw message
> 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


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


> 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?
Isaac Dunham <ibid.ag@gmail.com>
Details
Message ID
<20141027173701.GA1826@newbook>
In-Reply-To
<CAKv362tYmqmt96VK-dat1TPotHa0Xyt9PtwpEzcjCrWA9a+smA@mail.gmail.com> (view parent)
Sender timestamp
1414431421
DKIM signature
missing
Download raw message
On Mon, Oct 27, 2014 at 03:06:45PM +0000, 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
> 

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<80177A9D-09F2-478A-BB0D-7017F1122489@gmail.com>
In-Reply-To
<20141027173701.GA1826@newbook> (view parent)
Sender timestamp
1414432847
DKIM signature
missing
Download raw message
> 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.)

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.
Details
Message ID
<CAKv362tYmqmt96VK-dat1TPotHa0Xyt9PtwpEzcjCrWA9a+smA@mail.gmail.com>
In-Reply-To
<AD1CAE38-56FC-4EFC-8FE1-373D1BD689DA@gmail.com> (view parent)
Sender timestamp
1414422405
DKIM signature
missing
Download raw message
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 <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
>
>
> > 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.
>
>
> > 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?
>
>


-- 
Chris Spillane
Details
Message ID
<544E6D21.1000108@it-offshore.co.uk>
In-Reply-To
<CAKv362tYmqmt96VK-dat1TPotHa0Xyt9PtwpEzcjCrWA9a+smA@mail.gmail.com> (view parent)
Sender timestamp
1414425889
DKIM signature
missing
Download raw message
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 <systmkor@gmail.com
> <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
>
>
>     > 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.
>
>
>     > 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?
>
>
>
>
> -- 
> Chris Spillane
>
Daniel Cegiełka <daniel.cegielka@gmail.com>
Details
Message ID
<CAPLrYETBRm6eF2CVXnkf60iXXhVibB6GuF0o2PaKTHEoni0zKg@mail.gmail.com>
In-Reply-To
<544E6D21.1000108@it-offshore.co.uk> (view parent)
Sender timestamp
1414431077
DKIM signature
missing
Download raw message
2014-10-27 17:04 GMT+01:00 IT Developer <developer@it-offshore.co.uk>:
> 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.
>
>
>
> 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

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


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock <nenolod@dereferenced.org>
Details
Message ID
<CA+T2pCEywNiR9w-FyYXs1GpePguEWaJ1+aL5Lay=ghp1VyR92A@mail.gmail.com>
In-Reply-To
<AD1CAE38-56FC-4EFC-8FE1-373D1BD689DA@gmail.com> (view parent)
Sender timestamp
1415471177
DKIM signature
missing
Download raw message
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
---
Orion Miller <systmkor@gmail.com>
Details
Message ID
<CAPQg+vq7dVeWoAwgPh05F77FSSJ9T1u7ZxBG+boGkLO1g=dtQw@mail.gmail.com>
In-Reply-To
<CA+T2pCEywNiR9w-FyYXs1GpePguEWaJ1+aL5Lay=ghp1VyR92A@mail.gmail.com> (view parent)
Sender timestamp
1415660837
DKIM signature
missing
Download raw message
>
> 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.
Reply to thread Export thread (mbox)