X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) by lists.alpinelinux.org (Postfix) with ESMTP id B131B5C4E21 for ; Tue, 6 Feb 2018 22:29:16 +0000 (GMT) Received: by mail-wr0-f173.google.com with SMTP id s5so3633999wra.0 for ; Tue, 06 Feb 2018 14:29:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BtYtWrCIalZb9XwfVbinURCOZIwod1LeLJT8wB6IlvE=; b=B3beeBpOusPdGT6IVuI6gZh2ACEeAX0XI19EUEtdpJ+C6LQTdkSwRhoO5MGqKjTHCb Mxs4sc/XTxqpWDTNMRkHw6YrHa915zbqlGHMO1ZbbeVltIGBiYdg5IR2oMnliWXFKc2y 9YHXEW6nbYwcfK1U67DewZqBRV2tZtoMKXX0JFnvnbP9XpYFUQf4u0nszOVf/GlVEV3v REIMyLfJBgJDwQNMQ/oLYcrCMG1vpIs6XsRoqTMb5Cqh5rtgsp5KJ33PmG0tfKLstMfB ahd7Q1uBpY1Wkmw3i9z9Yn+xFJYCYCQj24Yb9rXXDW6Sxly9IAZybAy9jE3JLhiQ9YXY iing== X-Gm-Message-State: APf1xPBbytzdKd5AkgKwXG6j7z4kHGBRKY5KQqubxV1IK55+X+SDbpw8 VDaceh4TQAiRn+1K2HJnXqNwVXqjCYDsdzbQ0ZQ= X-Google-Smtp-Source: AH8x224+IeEpmoxwVzyae/2AKbA2jKu4jSKlQsYIjBrWx+OGYX1I99/eGRoFk+nPHZv9yGCcwL2X+jYAw/7HjScG8vA= X-Received: by 10.223.149.153 with SMTP id p25mr3955161wrp.155.1517956155803; Tue, 06 Feb 2018 14:29:15 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <5A0114AF.4050208@adelielinux.org> <20171107083614.15b25476@vostro.util.wtbts.net> In-Reply-To: <20171107083614.15b25476@vostro.util.wtbts.net> From: Kiyoshi Aman Date: Tue, 06 Feb 2018 22:29:05 +0000 Message-ID: Subject: Re: [alpine-devel] TLS library provider for makedepends To: Timo Teras Cc: "A. Wilcox" , alpine-dev Content-Type: multipart/alternative; boundary="f403045de7a8738cb3056492b5da" --f403045de7a8738cb3056492b5da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On Mon, 6 Nov 2017 20:04:31 -0600 > "A. Wilcox" wrote: > > > However, Ad=C3=A9lie targets 32-bit x86, 32-bit MIPS, 32-bit PowerPC, a= nd > > 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=C3=A9lie. 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=C3=A9lie) 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=3D"libssl-dev=3D1" 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=3D"libressl-dev=3D99999" 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 > --=20 -- Kiyoshi Aman --f403045de7a8738cb3056492b5da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think it's inappropriate for = libressl to be considered a replacement for openssl. Whether it's secur= e or not, the project has not kept its API compatibility promises, therefor= e making it impossible to compile software that is necessary for webapps su= ch 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.t= eras@iki.fi> wrote:
On Mon, = 6 Nov 2017 20:04:31 -0600
"A. Wilcox" <awilfox@adelielinux.org> wrote:

> However, Ad=C3=A9lie targets 32-bit x86, 32-bit MIPS, 32-bit PowerPC, = and
> 32-bit ARM.=C2=A0 Obviously this is therefore a quite significant issu= e for
> us.=C2=A0 We do not want to have to soft-fork every package in the Alp= ine
> aports repository that depends on OpenSSL or LibreSSL to change the > library provider.=C2=A0 I am soliciting ideas on how to move forward.<= br> >
> My own idea would be to make a libssl-dev virtual that is satisfied by=
> libressl-dev on Alpine and openssl-dev on Ad=C3=A9lie.=C2=A0 We can us= e 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=C3=A9lie) are welcome.=C2=A0 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=3D"libssl-dev=3D1" 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=3D"libressl-dev=3D99999" 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
--f403045de7a8738cb3056492b5da-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---