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
- Reply: Jung-uk Kim : "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"
- Reply: Cy Schubert : "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"
- Reply: Cy Schubert : "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"
- Reply: Pierre Pronchery : "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"
- In reply to: Antoine Brodin : "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"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 02 May 2023 21:24:05 UTC
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. -- John Baldwin