Date: Wed, 3 May 2023 16:54:53 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Pierre Pronchery <pierre@freebsdfoundation.org>, 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: <b2ea0517-e2ac-0c71-3d5c-cc32624d9b0f@FreeBSD.org> In-Reply-To: <u2up6s$mio$1@ciao.gmane.io> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com> <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> <u2up6s$mio$1@ciao.gmane.io>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/3/23 4:02 PM, Pierre Pronchery wrote: > 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?) You can use the EVP_* API if desired. tools/cryto/cryptocheck.c has examples of using the EVP_* APIs for both "plain" hashes and HMAC constructions -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b2ea0517-e2ac-0c71-3d5c-cc32624d9b0f>