From nobody Tue May 2 19:47:33 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9rGC1drNz49LGm for ; Tue, 2 May 2023 19:47:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9rGB3Cxcz47hy for ; Tue, 2 May 2023 19:47:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50bc394919cso4864608a12.2 for ; Tue, 02 May 2023 12:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1683056865; x=1685648865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Pj8Eo1JFCZKYugfDkalGV6kYLvPfEqQeXOUXjX82ZGc=; b=kzSAZ36pQ4445oiPmipbEz/3nxEUshAHfLA8xN8rYS8GzHVPGYh6B+X5HKsDs5u3bg WD/hBiaikNX9UqD3kULoiMkKWRFOsDl0RmE0xcKhUKFlsYDVgmlC1ayY/vUZ3JY2lYhn FeoZlUP5A/kWY9W9MyK0xvzyf07TdI2Q7jXH59xZZD7WfWD/TPbhyBg5jyrTapezT2BX ja2rYW9q1Cf2Vzj9mr3JeSjwP+RIw8mA99XFyOzose3bvZA38LarTgDFJhLhfQs6sTxG TEmHaxNSfobo4ssrix6X9K83g+ivyV8+KNrinf1/pKTmpWAwDl9P7WI0MBwHAOuIWj2o gf/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683056865; x=1685648865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Pj8Eo1JFCZKYugfDkalGV6kYLvPfEqQeXOUXjX82ZGc=; b=LEB7eRYf5SE6mX8zzdj2BmOptAO3t1unakSoy11gKaUl8KZ8TXy62FfH3369qafHh9 2wbR+T9vXiWLAfXX+LBMAswYtYQQ+K3RTLnDNnRvpT/Y8jpzpXO8bP1X88prq3+YLXja iEoj0bsSqAS16thezg8+Bb36h4y21REqorD6gDtrCA6vGLq07sQkqpN1WuhnlBVT5zAT jFuAI8j7WrcundXT3Y5R2iP4nprAM5m4fWn2hIrPitTu2DCVfru5gCsxeeFL/YvGb32z 4j9ARd5gzmHj+AhPhIdeZifvZOmhoDzK+DhzoJdxTCOZwH8bjT5YEfXHRgUq20gVQ8dy sHww== X-Gm-Message-State: AC+VfDzvIbOb5XWnxXjkeOlqLnJZucd1Uyb+sxwmmLVgXUoyE+Fl7m8m QWPVfQLlgQuO/qE/lriH+pYey4ueshSAK6l0Kw/rGQ== X-Google-Smtp-Source: ACHHUZ5dIuHXzUfW0SSEGcxUvZeLWJsS8gmRMQcCQeBHU+gDxFhKsFZv0096neV09XER3ffU4c3IRdLKa3RZePuYWwc= X-Received: by 2002:a17:907:9614:b0:94e:dd3f:b650 with SMTP id gb20-20020a170907961400b0094edd3fb650mr1134566ejc.18.1683056864713; Tue, 02 May 2023 12:47:44 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> <20230502120200.32c545e4@cschubert.com> In-Reply-To: <20230502120200.32c545e4@cschubert.com> From: Warner Losh Date: Tue, 2 May 2023 13:47:33 -0600 Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: Cy Schubert Cc: Jung-uk Kim , Rene Ladan , "A. Wilcox" , Enji Cooper , FreeBSD-arch list Content-Type: multipart/alternative; boundary="0000000000008ef52505fabb3621" X-Rspamd-Queue-Id: 4Q9rGB3Cxcz47hy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000008ef52505fabb3621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2023 at 1:02=E2=80=AFPM Cy Schubert wrote: > On Tue, 2 May 2023 10:42:32 -0400 > Jung-uk Kim wrote: > > > On 23. 5. 2., Rene Ladan wrote: > > > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote: > > >> On 23. 5. 1., A. Wilcox wrote: > > >>> On May 1, 2023, at 8:55 PM, Enji Cooper > wrote: > > >>>> Hello, > > >>>> One of the must-haves for 14.0-RELEASE is the introduction of > OpenSSL > > >>>> 3.0 into the base system. This is a must because, in short, OpenSS= L > > >>>> 1.1 is no longer supported as of 09/26/2023 [1]. > > >>>> > > >>>> I am proposing OpenSSL be made private along with all dependent > > >>>> libraries, for the following reasons: > > >>>> 1. More than a handful of core ports, e.g., security/py-cryptograp= hy > > >>>> [2] [3], still do not support OpenSSL 3.0. > > >>>> i. If other dependent ports (like lang/python38, etc) move to > OpenSSL > > >>>> 3, the distributed modules would break on load due to clashing > symbols > > >>>> if the right mix of modules were dlopen=E2=80=99ed in a specific o= rder > > >>>> (importing ssl, then importing hazmat=E2=80=99s crypto would fail)= . > > >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve > recommended > > >>>> on the 3.0 exp-run PR [4]. > > >>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking = in > > >>>> both libraries at runtime impossible without resorting to a number > of > > >>>> linker tricks hiding the namespaces using symbol prefixing of publ= ic > > >>>> symbols, etc. > > >>>> > > >>>> The libraries which would need to be made private are as follows: > > >>>> - kerberos > > >>>> - libarchive > > >>>> - libbsnmp > > >>>> - libfetch [5] > > >>>> - libgeli > > >>>> - libldns > > >>>> - libmp > > >>>> - libradius > > >>>> - libunbound > > >>>> > > >>>> I realize I=E2=80=99m jumping to a prescribed solution without add= itional > > >>>> discussion, but I=E2=80=99ve been doing offline analysis related t= o > uplifting > > >>>> code from OpenSSL 1.x to 3.x over the last several months and this > is > > >>>> the general prescribed solution I=E2=80=99ve come to which is need= ed for > > >>>> $work. My perspective might have some blind spots and some of the > > >>>> discussion done over IRC and might need to be rehashed here for > > >>>> historical reference/to widen the discussion for alternate solutio= ns > > >>>> that don=E2=80=99t have the degree of tunnel vision which the solu= tion I=E2=80=99m > > >>>> employing at $work requires. > > >>>> I=E2=80=99ve tried to include some of the previously involved part= ies so > they > > >>>> can chime in. > > >>>> Thank you, > > >>>> -Enji > > >>>> > > >>>> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > >>>> > > >>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > >>>> . > > >>>> 3. The reason why it hasn=E2=80=99t been upgraded is because newer= versions > > >>>> require rustc to build, which apparently doesn=E2=80=99t work on Q= EMU > builders > > >>>> due to missing emulation support: > > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > >>>> . > > >>>> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > >>>> > > >>>> 5. If I remember correctly, some folks suggested that making > libfetch > > >>>> private wasn=E2=80=99t required since the only port that required = it was > > >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. > > >>> > > >>> > > >>> Hi Enji (+ arch list), > > >>> > > >>> My opinion may not amount to much, but I=E2=80=99m not sure it make= s sense to > > >>> make it private solely for the sake of allowing ports to keep going > with > > >>> known insecure software. > > >>> > > >>> I think ports should be loudly warning, right now, that they requir= e > > >>> OpenSSL 1.x and there should be work with both upstreams and end > users > > >>> to seek out and migrate to OpenSSL 3. I, with others, have already > > >>> begun this work a while back in the Linux world. > > >>> > > >>> If the desire is to make these libraries private for future > > >>> improvements, or for the ability to swap in other another crypto/TL= S > > >>> implementation and perform experiments and innovate, then that seem= s > > >>> like it could be a useful tradeoff. However, if it=E2=80=99s just t= o allow > > >>> insecure software to continue to be used, I think that is ill > advised. > > >>> The global landscape of information security is different and I > think > > >>> it warrants a different response than maybe it would have in the > past. > > >>> And it should at least be a consideration to have a loud and > forceful > > >>> break in the interest of keeping data private and secure. > > >> > > >> +1 > > >> > > >> Jung-uk Kim > > > > > > (Randomly replying) > > > > > > Ports upstreams will probably take their time (if ever) to migrate of= f > > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private librar= y > > > for OpenSSL in base might also simply the SSL framework in ports (?) > > > > > > Ren=C3=A9 (personal hat only) > > > > Please note upgrading OpenSSL and having private library are orthogonal > > issues. I do not disagree with the private library idea if it is > > upgraded and well maintained. I believe sweeping security > > vulnerabilities under the rug is a recipe for disaster. > > Agreed. Making OpenSSL private doesn't mitigate the security risks. > It limits the blast radius... But creates a new blast zone... > Making base OpenSSL private -- and subsequently krb5, as discussed many > moons ago -- avoids all kinds of ports issues with the same symbols, > some as functions with different arguments. It took a while to work > through the various MIT/Heimdal Kerberos conflicts and other issues. > The reason to make it private is to avoid difficult to resolve > conflicts with packages of the same name in ports. > Yes. We don't want to be in a situation where we can't upgrade the base openssl because of excess port entanglement... Moving to private solves that problem... for base. > On the ports side, some ports will require OpenSSL 1.1.1 while others > will use 1.1.1 or 3.x. Package mutual exclusivity will affect users > wish to install package A with OpenSSL 1.1.1 prerequisite with package > pB with OpenSSL 3.X prerequistite. The ports team may need different > flavors of various packages. > > The deeper we drill into this greater the number of landmines. This > might require a roadmap. > But does expose (I won't say create, because this issue is orthogonal to the openssl in base) an issue other projects are coping with, somehow. Warner > > > > Jung-uk Kim > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > --0000000000008ef52505fabb3621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 2, 2023 at 1:02=E2=80=AFP= M Cy Schubert <Cy.Schubert@= cschubert.com> wrote:
On Tue, 2 May 2023 10:42:32 -0400
Jung-uk Kim <jkim@FreeBSD.org> wrote:

> On 23. 5. 2., Rene Ladan wrote:
> > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote:=C2= =A0
> >> On 23. 5. 1., A. Wilcox wrote:=C2=A0
> >>> On May 1, 2023, at 8:55 PM, Enji Cooper <yaneurabeya@gmail.com>= wrote:=C2=A0
> >>>> Hello,
> >>>> One of the must-haves for 14.0-RELEASE is the introdu= ction of OpenSSL
> >>>> 3.0 into the base system. This is a must because, in = short, OpenSSL
> >>>> 1.1 is no longer supported as of 09/26/2023 [1].
> >>>>
> >>>> I am proposing OpenSSL be made private along with all= dependent
> >>>> libraries, for the following reasons:
> >>>> 1. More than a handful=C2=A0of core ports, e.g., secu= rity/py-cryptography
> >>>> [2] [3], still do not support OpenSSL 3.0.
> >>>> i.=C2=A0If other dependent ports (like lang/python38,= etc) move to OpenSSL
> >>>> 3, the distributed modules would break on load due to= clashing symbols
> >>>> if the right mix of modules were dlopen=E2=80=99ed in= a specific order
> >>>> (importing ssl, then importing hazmat=E2=80=99s crypt= o would fail).
> >>>> ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended
> >>>> on the 3.0 exp-run PR [4].
> >>>> 2.=C2=A0OpenSSL 1.1 and 3.0 have clashing symbols, wh= ich makes linking in
> >>>> both libraries at runtime impossible without resortin= g to a number of
> >>>> linker tricks hiding the namespaces using symbol pref= ixing of public
> >>>> symbols, etc.
> >>>>
> >>>> The libraries which would need to be made private are= as follows:
> >>>> - kerberos
> >>>> - libarchive
> >>>> - libbsnmp
> >>>> - libfetch [5]
> >>>> - libgeli
> >>>> - libldns
> >>>> - libmp
> >>>> - libradius
> >>>> - libunbound
> >>>>
> >>>> I realize I=E2=80=99m jumping to a prescribed solutio= n without additional
> >>>> discussion, but I=E2=80=99ve been doing offline analy= sis related to uplifting
> >>>> code from OpenSSL 1.x to 3.x over the last several mo= nths and this is
> >>>> the general prescribed solution I=E2=80=99ve come to = which is needed for
> >>>> $work. My perspective might have some blind spots and= some of the
> >>>> discussion done over IRC and might need to be rehashe= d here for
> >>>> historical reference/to widen the discussion for alte= rnate solutions
> >>>> that don=E2=80=99t have the degree of tunnel vision w= hich the solution I=E2=80=99m
> >>>> employing at $work requires.
> >>>> I=E2=80=99ve tried to include some of the previously = involved parties so they
> >>>> can chime in.
> >>>> Thank you,
> >>>> -Enji
> >>>>
> >>>> 1. https://www.openssl.= org/blog/blog/2023/03/28/1.1.1-EOL/
> >>>> <https://www.openssl= .org/blog/blog/2023/03/28/1.1.1-EOL/>
> >>>> 2. https://bugs.free= bsd.org/bugzilla/show_bug.cgi?id=3D254853
> >>>> <https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853>=C2=A0.
> >>>> 3. The reason why it hasn=E2=80=99t been upgraded is = because newer versions
> >>>> require rustc to build, which apparently doesn=E2=80= =99t work on QEMU builders
> >>>> due to missing emulation support:
> >>>> https://bugs.freebsd= .org/bugzilla/show_bug.cgi?id=3D254853
> >>>> <https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853>=C2=A0.
> >>>> 4. https://bugs.= freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15
> >>>> <https://bugs= .freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15>
> >>>> 5. If I remember correctly, some folks suggested that= making libfetch
> >>>> private wasn=E2=80=99t required since the only port t= hat required it was
> >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this = claim.=C2=A0
> >>>
> >>>
> >>> Hi Enji (+ arch list),
> >>>
> >>> My opinion may not amount to much, but I=E2=80=99m not su= re it makes sense to
> >>> make it private solely for the sake of allowing ports to = keep going with
> >>> known insecure software.
> >>>
> >>> I think ports should be loudly warning, right now, that t= hey require
> >>> OpenSSL 1.x and there should be work with both upstreams = and end users
> >>> to seek out and migrate to OpenSSL 3.=C2=A0 I, with other= s, have already
> >>> begun this work a while back in the Linux world.
> >>>
> >>> If the desire is to make these libraries private for futu= re
> >>> improvements, or for the ability to swap in other another= crypto/TLS
> >>> implementation and perform experiments and innovate, then= that seems
> >>> like it could be a useful tradeoff. However, if it=E2=80= =99s just to allow
> >>> insecure software to continue to be used, I think that is= ill advised.
> >>>=C2=A0 =C2=A0=C2=A0The global landscape of information sec= urity is different and I think
> >>> it warrants a different response than maybe it would have= in the past.
> >>>=C2=A0 =C2=A0=C2=A0And it should at least be a considerati= on to have a loud and forceful
> >>> break in the interest of keeping data private and secure.= =C2=A0
> >>
> >> +1
> >>
> >> Jung-uk Kim=C2=A0
> >
> > (Randomly replying)
> >
> > Ports upstreams will probably take their time (if ever) to migrat= e off
> > OpenSSL 1.X, as we have seen with Python 2.7. Having a private li= brary
> > for OpenSSL in base might also simply the SSL framework in ports = (?)
> >
> > Ren=C3=A9 (personal hat only)=C2=A0
>
> Please note upgrading OpenSSL and having private library are orthogona= l
> issues.=C2=A0 I do not disagree with the private library idea if it is=
> upgraded and well maintained.=C2=A0 I believe sweeping security
> vulnerabilities under the rug is a recipe for disaster.

Agreed. Making OpenSSL private doesn't mitigate the security risks.
=

It limits the blast radius...=C2=A0 But cr= eates a new blast zone...
=C2=A0
Making base OpenSSL private -- and subsequently krb5, as discussed many
moons ago -- avoids all kinds of ports issues with the same symbols,
some as functions with different arguments. It took a while to work
through the various MIT/Heimdal Kerberos conflicts and other issues.
The reason to make it private is to avoid difficult to resolve
conflicts with packages of the same name in ports.
Yes. We don't want to be in a situation where we can't = upgrade the base
openssl because of excess port entanglement... M= oving to private
solves that problem... for base.
=C2= =A0
On the ports side, some ports will require OpenSSL 1.1.1 while others
will use 1.1.1 or 3.x. Package mutual exclusivity will affect users
wish to install package A with OpenSSL 1.1.1 prerequisite with package
p= B with OpenSSL 3.X prerequistite. The ports team may need different
flavors of various packages.

The deeper we drill into this greater the number of landmines. This
might require a roadmap.

But does expos= e (I won't say create, because this issue is orthogonal
to th= e openssl in base) an issue other projects are coping with, somehow.
<= div>
Warner
=C2=A0
>
> Jung-uk Kim



--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeB= SD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:=C2=A0 https://nwt= ime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0

--0000000000008ef52505fabb3621--