-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJaARSpAAoJEMspy1GSK50Ue3gP/3hbm4cWQXJqlKbnEUaFMx/j
wpFjfbgDWJ0f6rEfHWbn/Jo7dMnG/bi13T7S7yy8fzgG3rgmZllCoaQI2ffG6mFg
MrNiNTmMP2W4f2ozPt7Qqbvgg4JZOpUKdtymDTwfTXQM4m3VxZVd/U1JdBqGC7X8
FabN8xn35AbD5bYXKoZdGjJCwdwJg7QbvkefhAP+AwggK+X5X606WPWtBIjca0Rt
M4Bug5JqIKSPwUe3vetVQ0T0y6OX9FURLej+pTeIKL7h7vYUb1frwvSCH8wDsygW
d+HBuBOr8VjD3ZRoDEzsdpggdh9GJH0cFtcB/KbyYLkAb1VPSTDZ6J8RXVQ7ci1+
3iQqu2uMEhFU8WZOiJliXc+fblusX0z4IyOUz9ZGXc+5LqVwJ63NSWsRNh5tEcEe
U0TxhuLk2iesvYVz3YjdPSFiIXXXTzRTLG2ogpMMwzFsoLS9PKa71beXRuQvEFdM
CLORLidXsQHWf4+aA6CFz6f581lf9DJHuUx3wWLAbOXCIigg3YAgH0NuSsbQ7qMI
shTC5G4Nq2QbC2Lhg5kwBPEJVrdOG8vxAxuZ7FynUY2JbjjWiCwS4AcxE2qFmmPI
REqh5rUFY4Qjwd7lUm5On6zqZ0Ul8ejXege4AhHzPV/+Z9ekRgTJoLUnNtbFMzbX
ekveW9n8BoeHWwjhD3Ly
=yhfA
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Mon, 6 Nov 2017 20:04:31 -0600
"A. Wilcox" <awilfox@adelielinux.org> wrote:
> 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.
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
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.
On Tue, Nov 7, 2017 at 12:36 AM Timo Teras <timo.teras@iki.fi> wrote:
> On Mon, 6 Nov 2017 20:04:31 -0600> "A. Wilcox" <awilfox@adelielinux.org> wrote:>> > 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.>> 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>
--
-- Kiyoshi Aman
I heard good things about BearSSL.
https://bearssl.org/
On Tue, Feb 6, 2018 at 8:29 PM, Kiyoshi Aman <aphrael@alpinelinux.org> wrote:
> 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.>> On Tue, Nov 7, 2017 at 12:36 AM Timo Teras <timo.teras@iki.fi> wrote:>>>> On Mon, 6 Nov 2017 20:04:31 -0600>> "A. Wilcox" <awilfox@adelielinux.org> wrote:>>>> > 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.>>>> 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>> --> -- Kiyoshi Aman
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
>I heard good things about BearSSL.>https://bearssl.org/
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
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---