Date: Tue, 2 May 2023 09:59:32 +0000 From: Antoine Brodin <antoine@freebsd.org> To: Enji Cooper <yaneurabeya@gmail.com> Cc: 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: <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com> In-Reply-To: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 2, 2023 at 1:55=E2=80=AFAM 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 = 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-cryptography [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 order (importing = ssl, then importing hazmat=E2=80=99s crypto would fail). > ii. Such ports should be deprecated/marked broken as I=E2=80=99ve recomme= nded 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 tr= icks 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. Antoine > I realize I=E2=80=99m jumping to a prescribed solution without additional= discussion, but I=E2=80=99ve been doing offline analysis related to uplift= ing code from OpenSSL 1.x to 3.x over the last several months and this is t= he general prescribed solution I=E2=80=99ve come to which is needed for $wo= rk. My perspective might have some blind spots and some of the discussion d= one over IRC and might need to be rehashed here for historical reference/to= widen the discussion for alternate solutions that don=E2=80=99t have the d= egree of tunnel vision which the solution I=E2=80=99m employing at $work re= quires. > 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/ > 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 versio= ns require rustc to build, which apparently doesn=E2=80=99t work on QEMU bu= ilders 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 pri= vate 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg>