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 Tuesday, May 2nd, 2023 at 10:28 AM, Rene Ladan <rene@freebsd.org> 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)

(Randomly replying)

Hello.

Personally I think that all base libs presented in ports should be private.

As example: ncurses.

Some ports have option to select base/ports to use.
Some unconditionally require ncurses from ports.
Some will be linked with ncurses from ports if it installed, otherwise ncurses
from base.
Some unconditionally linked with base version.

And when some library linked with base ncurses and it used by another port that
linked with ncurses from ports we can see a binary that requires ncurses from
base AND ncurses from ports at the same time. Some times it leads to issues.

- Oleh