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

John Baldwin <[email protected]>
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
On 5/2/23 2:59 AM, Antoine Brodin wrote:
> On Tue, May 2, 2023 at 1:55 AM Enji Cooper <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.