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 message <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>, John Baldwin 
wri
tes:
> 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 lon
> ger 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, t
> he distributed modules would break on load due to clashing symbols if the rig
> ht mix of modules were dlopen’ed in a specific order (importing ssl, then i
> mporting 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 trick
> s 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.

Exactly. They're idependent problems.

>
> -- 
> John Baldwin


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0