Subject: [alpine-devel] TLS library provider for makedepends

From: "A. Wilcox" <[email-masked]>
Date: Mon, 6 Nov 2017 20:04:31 -0600

Hello there Alpinists,

LibreSSL has issues on 32-bit platforms[1] that they will not fix.
They claim that this is a "kernel ABI issue" and that they do not want
to use a custom time type when time_t is 32-bit, which is the case on
32-bit Linux right now.[2]  This is likely to remain an issue for a
number of years (conservative estimates from the linked article put a
32-bit ABI with 64-bit time_t as appearing in 2021 or later).

This is a growing issue with root CA certificates being issued with
long (20+ year) expirations; in fact, some software have already had
to roll back to OpenSSL on 32-bit platforms due to this.[3]  OpenSSL
is not affected by this bug as of 1.0.0.[4]

Additionally, the LibreSSL team is notoriously hostile[5] to Linux
developers.  I have had personal run-ins with members of their team
that has made me wish to avoid working with them.

This is likely not an issue for Alpine as 32-bit platforms are not
really supported as far as I can tell.  32-bit PowerPC is not a
target, 32-bit ARM breaks constantly and is not a priority[6], and
32-bit x86 is being dropped for 3.8[7].

However, Adélie targets 32-bit x86, 32-bit MIPS, 32-bit PowerPC, and
32-bit ARM.  Obviously this is therefore a quite significant issue for
us.  We do not want to have to soft-fork every package in the Alpine
aports repository that depends on OpenSSL or LibreSSL to change the
library provider.  I am soliciting ideas on how to move forward.

My own idea would be to make a libssl-dev virtual that is satisfied by
libressl-dev on Alpine and openssl-dev on Adélie.  We can use the new
provides_priority to accomplish this, and then we only have to
soft-fork the OpenSSL package.

Other ideas (that do not include dropping 32-bit architectures from
Adélie) are welcome.  Let's discuss.

Best to you and yours,
- --arw

[1]: https://github.com/libressl-portable/portable/issues/207
[2]: https://lwn.net/Articles/717076/
[3]: https://github.com/LibreELEC/LibreELEC.tv/pull/1312
[4]:
http://openssl.6102.n7.nabble.com/Year-2038-and-CA-certificate-td15936.h
tml
[5]: https://github.com/libressl-portable/portable/issues/307
[6]: #alpine-devel IRC from September 2017 (missing from irclogger)
[7]: http://www.irclogger.com/.alpine-devel/2017-02-01#1485934934

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org

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

---

From: Timo Teras <[email-masked]>
Date: Tue, 7 Nov 2017 08:36:26 +0200

On Mon, 6 Nov 2017 20:04:31 -0600

> Adélie) are welcome.  Let's discuss.

This sounds like good idea to me. We don't need to even wait for
provides_priority stuff, just use versioned provides since the two
packages cannot co-exist.

provides="libssl-dev=1" or similar for the package in aports that
should be used, and apk will automatically use it. And update all
makedepends for the new package name.

As alternative, on Adelie, you could just do in openssl-dev
provides="libressl-dev=99999" and it would be preferred over openssl.

But would be nice to get rid of the package specific name and migrate
to 'libssl-dev' or 'ssl-dev'. 

Other thoughts?

Timo

---

From: Kiyoshi Aman <[email-masked]>
Date: Tue, 06 Feb 2018 22:29:05 +0000

Hi,

I think it's inappropriate for libressl to be considered a replacement for
openssl. Whether it's secure or not, the project has not kept its API
compatibility promises, therefore making it impossible to compile software
that is necessary for webapps such as taiga. Consequently, I support
returning to openssl as system default, and only keeping libressl around
for software which actually requires it.

-- 
-- Kiyoshi Aman

---

From: Alba Pompeo <[email-masked]>
Date: Thu, 8 Feb 2018 08:53:35 -0200

I heard good things about BearSSL.
https://bearssl.org/

On Tue, Feb 6, 2018 at 8:29 PM, Kiyoshi Aman <[email-masked]> wrote:
> returning to openssl as system default, and only keeping libressl around for
> software which actually requires it.
>

---

---

From: "Laurent Bercot" <[email-masked]>
Date: Thu, 08 Feb 2018 11:38:46 +0000

>I heard good things about BearSSL.

  Yes, BearSSL is very good (and I'm going to package it for Alpine as
soon as I get the time).

  However, it's nowhere near a drop-in replacement for OpenSSL or
LibreSSL, so unless people are willing to rewrite software to work
with the BearSSL API, it's entirely irrelevant to the question of what
library to use as the system default.

--
  Laurent

---