Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 May 2023 14:24:05 -0700
From:      John Baldwin <jhb@FreeBSD.org>
To:        Antoine Brodin <antoine@freebsd.org>, 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:  <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>
In-Reply-To: <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com>
References:  <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12f8559c-d696-5344-98d5-1751d04088af>