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

On Tue, May 2, 2023 at 1:02 PM Cy Schubert <Cy.Schubert@cschubert.com>
wrote:

> On Tue, 2 May 2023 10:42:32 -0400
> Jung-uk Kim <jkim@FreeBSD.org> wrote:
>
> > On 23. 5. 2., Rene Ladan wrote:
> > > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote:
> > >> On 23. 5. 1., A. Wilcox wrote:
> > >>> On May 1, 2023, at 8:55 PM, 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
> > >>>>
> > >>>> I realize I’m jumping to a prescribed solution without additional
> > >>>> discussion, but I’ve been doing offline analysis related to
> uplifting
> > >>>> code from OpenSSL 1.x to 3.x over the last several months and this
> is
> > >>>> the general prescribed solution I’ve come to which is needed for
> > >>>> $work. My perspective might have some blind spots and some of the
> > >>>> discussion done over IRC and might need to be rehashed here for
> > >>>> historical reference/to widen the discussion for alternate solutions
> > >>>> that don’t have the degree of tunnel vision which the solution I’m
> > >>>> employing at $work requires.
> > >>>> I’ve tried to include some of the previously involved parties so
> they
> > >>>> can chime in.
> > >>>> Thank you,
> > >>>> -Enji
> > >>>>
> > >>>> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> > >>>> <https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/>
> > >>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853
> > >>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853> .
> > >>>> 3. The reason why it hasn’t been upgraded is because newer versions
> > >>>> require rustc to build, which apparently doesn’t work on QEMU
> builders
> > >>>> due to missing emulation support:
> > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853
> > >>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853> .
> > >>>> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413#c15
> > >>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413#c15>
> > >>>> 5. If I remember correctly, some folks suggested that making
> libfetch
> > >>>> private wasn’t required since the only port that required it was
> > >>>> ports-mgmt/pkg, but I haven’t validated this claim.
> > >>>
> > >>>
> > >>> Hi Enji (+ arch list),
> > >>>
> > >>> My opinion may not amount to much, but I’m not sure it makes sense to
> > >>> make it private solely for the sake of allowing ports to keep going
> with
> > >>> known insecure software.
> > >>>
> > >>> I think ports should be loudly warning, right now, that they require
> > >>> OpenSSL 1.x and there should be work with both upstreams and end
> users
> > >>> to seek out and migrate to OpenSSL 3.  I, with others, have already
> > >>> begun this work a while back in the Linux world.
> > >>>
> > >>> If the desire is to make these libraries private for future
> > >>> improvements, or for the ability to swap in other another crypto/TLS
> > >>> implementation and perform experiments and innovate, then that seems
> > >>> like it could be a useful tradeoff. However, if it’s just to allow
> > >>> insecure software to continue to be used, I think that is ill
> advised.
> > >>>    The global landscape of information security is different and I
> think
> > >>> it warrants a different response than maybe it would have in the
> past.
> > >>>    And it should at least be a consideration to have a loud and
> forceful
> > >>> break in the interest of keeping data private and secure.
> > >>
> > >> +1
> > >>
> > >> Jung-uk Kim
> > >
> > > (Randomly replying)
> > >
> > > Ports upstreams will probably take their time (if ever) to migrate off
> > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private library
> > > for OpenSSL in base might also simply the SSL framework in ports (?)
> > >
> > > René (personal hat only)
> >
> > Please note upgrading OpenSSL and having private library are orthogonal
> > issues.  I do not disagree with the private library idea if it is
> > upgraded and well maintained.  I believe sweeping security
> > vulnerabilities under the rug is a recipe for disaster.
>
> Agreed. Making OpenSSL private doesn't mitigate the security risks.
>

It limits the blast radius...  But creates a new blast zone...


> Making base OpenSSL private -- and subsequently krb5, as discussed many
> moons ago -- avoids all kinds of ports issues with the same symbols,
> some as functions with different arguments. It took a while to work
> through the various MIT/Heimdal Kerberos conflicts and other issues.
> The reason to make it private is to avoid difficult to resolve
> conflicts with packages of the same name in ports.
>

Yes. We don't want to be in a situation where we can't upgrade the base
openssl because of excess port entanglement... Moving to private
solves that problem... for base.


> On the ports side, some ports will require OpenSSL 1.1.1 while others
> will use 1.1.1 or 3.x. Package mutual exclusivity will affect users
> wish to install package A with OpenSSL 1.1.1 prerequisite with package
> pB with OpenSSL 3.X prerequistite. The ports team may need different
> flavors of various packages.
>
> The deeper we drill into this greater the number of landmines. This
> might require a roadmap.
>

But does expose (I won't say create, because this issue is orthogonal
to the openssl in base) an issue other projects are coping with, somehow.

Warner


> >
> > Jung-uk Kim
>
>
>
> --
> 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
>
>