Date: Tue, 2 May 2023 07:28:51 +0000 From: Rene Ladan <rene@freebsd.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: "A. Wilcox" <AWilcox@wilcox-tech.com>, Enji Cooper <yaneurabeya@gmail.com>, FreeBSD-arch list <freebsd-arch@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: <ZFC7s1Z8PxtRxgyR@freefall.freebsd.org> In-Reply-To: <eb7eddfe-5e7a-468d-e2fe-7b7ae6517aad@FreeBSD.org> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> <eb7eddfe-5e7a-468d-e2fe-7b7ae6517aad@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZFC7s1Z8PxtRxgyR>