Date: Tue, 02 May 2023 08:13:09 +0000 From: cglogic <cglogic@protonmail.com> To: 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: <eVIdxUTM-V5RxD89BPvIWJNVg1fikEalGnYJmUD0iCpEH0EkPoaDigx6HE0XK1O1X7onpRkSgkbkv5b4V48juHu0GezcIrWbmDvQq5_VWQY=@protonmail.com> In-Reply-To: <ZFC7s1Z8PxtRxgyR@freefall.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> <ZFC7s1Z8PxtRxgyR@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 > > On 23. 5. 1., A. Wilcox wrote: > >=20 > > > On May 1, 2023, at 8:55 PM, Enji Cooper yaneurabeya@gmail.com wrote: > > >=20 > > > > Hello, > > > > One of the must-haves for 14.0-RELEASE is the introduction of OpenS= SL > > > > 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]. > > > >=20 > > > > 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-cryptograph= y > > > > [2] [3], still do not support OpenSSL 3.0. > > > > i. If other dependent ports (like lang/python38, etc) move to OpenS= SL > > > > 3, the distributed modules would break on load due to clashing symb= ols > > > > if the right mix of modules were dlopen=E2=80=99ed in a specific or= der > > > > (importing ssl, then importing hazmat=E2=80=99s crypto would fail). > > > > ii. Such ports should be deprecated/marked broken as I=E2=80=99ve r= ecommended > > > > on the 3.0 exp-run PR [4]. > > > > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking i= n > > > > both libraries at runtime impossible without resorting to a number = of > > > > linker tricks hiding the namespaces using symbol prefixing of publi= c > > > > symbols, etc. > > > >=20 > > > > The libraries which would need to be made private are as follows: > > > > - kerberos > > > > - libarchive > > > > - libbsnmp > > > > - libfetch [5] > > > > - libgeli > > > > - libldns > > > > - libmp > > > > - libradius > > > > - libunbound > > > >=20 > > > > I realize I=E2=80=99m jumping to a prescribed solution without addi= tional > > > > discussion, but I=E2=80=99ve 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=E2=80=99ve come to which is neede= d 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 solution= s > > > > that don=E2=80=99t have the degree of tunnel vision which the solut= ion I=E2=80=99m > > > > employing at $work requires. > > > > I=E2=80=99ve tried to include some of the previously involved parti= es so they > > > > can chime in. > > > > Thank you, > > > > -Enji > > > >=20 > > > > 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=3D254853 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > > > > 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions > > > > require rustc to build, which apparently doesn=E2=80=99t work on QE= MU builders > > > > due to missing emulation support: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > > > > 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > > > 5. If I remember correctly, some folks suggested that making libfet= ch > > > > private wasn=E2=80=99t required since the only port that required i= t was > > > > ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. > > >=20 > > > Hi Enji (+ arch list), > > >=20 > > > My opinion may not amount to much, but I=E2=80=99m not sure it makes = sense to > > > make it private solely for the sake of allowing ports to keep going w= ith > > > known insecure software. > > >=20 > > > 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 user= s > > > to seek out and migrate to OpenSSL 3. I, with others, have already > > > begun this work a while back in the Linux world. > > >=20 > > > 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=E2=80=99s 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. > >=20 > > +1 > >=20 > > Jung-uk Kim >=20 >=20 > (Randomly replying) >=20 > 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 (?) >=20 > Ren=C3=A9 (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 ncur= ses 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 fr= om base AND ncurses from ports at the same time. Some times it leads to issues= . - Oleh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eVIdxUTM-V5RxD89BPvIWJNVg1fikEalGnYJmUD0iCpEH0EkPoaDigx6HE0XK1O1X7onpRkSgkbkv5b4V48juHu0GezcIrWbmDvQq5_VWQY=>