Date: Tue, 2 May 2023 12:02:06 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: Rene Ladan <rene@freebsd.org>, "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: <20230502120200.32c545e4@cschubert.com> In-Reply-To: <deffec4c-8c34-b1e3-6820-2455db98c771@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> <deffec4c-8c34-b1e3-6820-2455db98c771@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: =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 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=C2=A0of core ports, e.g., security/py-cryptog= raphy > >>>> [2] [3], still do not support OpenSSL 3.0. > >>>> i.=C2=A0If other dependent ports (like lang/python38, etc) move to O= penSSL > >>>> 3, the distributed modules would break on load due to clashing symbo= ls > >>>> if the right mix of modules were dlopen=E2=80=99ed in a specific ord= er > >>>> (importing ssl, then importing hazmat=E2=80=99s crypto would fail). > >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve re= commended > >>>> on the 3.0 exp-run PR [4]. > >>>> 2.=C2=A0OpenSSL 1.1 and 3.0 have clashing symbols, which makes linki= ng 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=E2=80=99m jumping to a prescribed solution without addit= ional > >>>> 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 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=E2=80=99t have the degree of tunnel vision which the soluti= on I=E2=80=99m > >>>> employing at $work requires. > >>>> I=E2=80=99ve tried to include some of the previously involved partie= s 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=3D254853 > >>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853>=C2=A0. > >>>> 3. The reason why it hasn=E2=80=99t been upgraded is because newer v= ersions > >>>> require rustc to build, which apparently doesn=E2=80=99t work on QEM= U 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>=C2=A0. > >>>> 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 libfetch > >>>> private wasn=E2=80=99t required since the only port that required it= was > >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. =20 > >>> > >>> > >>> Hi Enji (+ arch list), > >>> > >>> 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. > >>> > >>> 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. =C2=A0I, with others, have alre= ady > >>> 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=E2=80=99s just to = allow > >>> insecure software to continue to be used, I think that is ill advised. > >>> =C2=A0The global landscape of information security is different and= I think > >>> it warrants a different response than maybe it would have in the past. > >>> =C2=A0And 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 > >> > >> 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) =20 >=20 > Please note upgrading OpenSSL and having private library are orthogonal=20 > issues. I do not disagree with the private library idea if it is=20 > upgraded and well maintained. I believe sweeping security=20 > vulnerabilities under the rug is a recipe for disaster. Agreed. Making OpenSSL private doesn't mitigate the security risks. 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. 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 B 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. >=20 > Jung-uk Kim --=20 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=3D0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230502120200.32c545e4>