Date: Thu, 4 May 2023 01:02:52 +0200 From: Pierre Pronchery <pierre@freebsdfoundation.org> To: freebsd-arch@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: <u2up6s$mio$1@ciao.gmane.io> 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
Hi everyone, On 5/2/23 23:24, John Baldwin wrote: > 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 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’ed in a specific >>> order (importing ssl, then importing 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 tricks 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. I have started to look at updating OpenSSL to version 3.0.8 in base, using the existing vendor/openssl-3.0 branch. My progress can be found at https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I regularly force-push to keep a consistent and nice commit history, before possibly applying for a merge. So far the status is: - libssl, libcrypto build on amd64, i386, less sure about aarch64, other architectures not tested - libfetch builds, uses libmd in addition to OpenSSL - libradius builds, same thing - libarchive builds - libunbound builds, but not unbound - libmp builds I used libmd to reach a buildable status faster, since the equivalent MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in OpenSSL 3, we can avoid the dependency on libmd again. (anyone got sample code for this?) Meanwhile I keep trying to build the rest of the system, hopefully in time for a possible inclusion in -14. Reviews and tests on the whole thing will be more than welcome in any case! Cheers & HTH, -- Pierre Pronchery
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?u2up6s$mio$1>