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 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)