Date: Tue, 02 May 2023 14:55:57 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Antoine Brodin <antoine@freebsd.org>, Enji Cooper <yaneurabeya@gmail.com>, FreeBSD-arch list <freebsd-arch@freebsd.org>, bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert <cy@freebsd.org>, Ed Maste <emaste@freebsd.org>, vishwin@freebsd.org 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 Message-ID: <20230502215557.AE65339A@slippy.cwsent.com> In-Reply-To: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com> <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>, John Baldwin wri tes: > On 5/2/23 2:59 AM, Antoine Brodin wrote: > > On Tue, May 2, 2023 at 1:55 AM Enji Cooper <yaneurabeya@gmail.com> 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, OpenSSL 1.1 is no lon > ger 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-cryptography [2] [ > 3], still do not support OpenSSL 3.0. > >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, t > he distributed modules would break on load due to clashing symbols if the rig > ht mix of modules were dlopen’ed in a specific order (importing ssl, then i > mporting hazmat’s crypto would fail). > >> ii. Such ports should be deprecated/marked broken as I’ve 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 trick > s hiding the namespaces using symbol prefixing 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 > > > > In my opinion this is a huge amount of work a few weeks before the > > release. Focusing on updating OpenSSL and those core ports may be > > simpler. > > This is my view. I think making OpenSSL private is a very huge task, and > fraught with peril in ways that haven't been thought about yet (e.g. PAM) > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I think > we need to be moving forward with OpenSSL 3 in base as-is. We will have to > fix ports to work with OpenSSL 3 regardless (though this does make that pain > in ports happen sooner). Moving libraries private can happen orthogonally > with getting base to work with OpensSL 3. Exactly. They're idependent problems. > > -- > John Baldwin -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230502215557.AE65339A>