Date: Wed, 3 May 2023 17:36:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Pierre Pronchery <pierre@freebsdfoundation.org> Cc: "freebsd-arch@freebsd.org" <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: <CANCZdfr3a-QjWMco8UPvqD62d77StkWqAF%2BuJypc6Vi3jw8i1g@mail.gmail.com> In-Reply-To: <u2up6s$mio$1@ciao.gmane.io> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> <CAALwa8m7P2daUd9%2BS4oBXqexBrczcXnmL6sGJ8fR4gwJDPDbcg@mail.gmail.com> <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> <u2up6s$mio$1@ciao.gmane.io>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e673af05fad287be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2023, 5:10 PM Pierre Pronchery <pierre@freebsdfoundation.org= > wrote: > Hi everyone, > > On 5/2/23 23:24, John Baldwin wrote: > > On 5/2/23 2:59 AM, Antoine Brodin wrote: > >> On Tue, May 2, 2023 at 1:55=E2=80=AFAM 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=E2=80=99ed in a speci= fic > >>> order (importing ssl, then importing hazmat=E2=80=99s crypto would fa= il). > >>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve rec= ommended > >>> 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 > >> > >> In my opinion this is a huge amount of work a few weeks before the > >> release. Focusing on updating OpenSSL and those core ports may be > >> simpler. > > > > This is my view. I think making OpenSSL private is a very huge task, a= nd > > fraught with peril in ways that haven't been thought about yet (e.g. PA= M) > > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I > > think > > we need to be moving forward with OpenSSL 3 in base as-is. We will hav= e > to > > fix ports to work with OpenSSL 3 regardless (though this does make that > > pain > > in ports happen sooner). Moving libraries private can happen > orthogonally > > with getting base to work with OpensSL 3. > > I have started to look at updating OpenSSL to version 3.0.8 in base, > using the existing vendor/openssl-3.0 branch. > > My progress can be found at > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I > regularly force-push to keep a consistent and nice commit history, > before possibly applying for a merge. > > So far the status is: > > - libssl, libcrypto build on amd64, i386, less sure about aarch64, other > architectures not tested > - libfetch builds, uses libmd in addition to OpenSSL > - libradius builds, same thing > - libarchive builds > - libunbound builds, but not unbound > - libmp builds > > I used libmd to reach a buildable status faster, since the equivalent > MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in > OpenSSL 3, we can avoid the dependency on libmd again. (anyone got > sample code for this?) > > Meanwhile I keep trying to build the rest of the system, hopefully in > time for a possible inclusion in -14. > > Reviews and tests on the whole thing will be more than welcome in any cas= e! > Cool. Id like to echo the namespace remapping suggestion. OpenSSL tends to be basically a leaf requirement. If we always remapping our in tree openssl, then if someone uses, say, libfetch and something else that requires openssl1, they can coexist in the same binary. Without the namespace remapping, we get a guaranteed conflict. It would increase our flexibility. And it could potentially be mfc'd if the old openssl were left as an optional component for people on stable stuck with it as a requirement. It would mitigate the EOL issues while giving an escape hatch that's not insane (modulo the elevated risk) I'll have to take a closer look at the branch. Warner Cheers & HTH, > -- > Pierre Pronchery > > > --000000000000e673af05fad287be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Wed, May 3, 2023, 5:10 PM Pierre Pronchery <<a h= ref=3D"mailto:pierre@freebsdfoundation.org">pierre@freebsdfoundation.org</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi everyone,<br> <br> On 5/2/23 23:24, John Baldwin wrote:<br> > On 5/2/23 2:59 AM, Antoine Brodin wrote:<br> >> On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper <<a href=3D"= mailto:yaneurabeya@gmail.com" target=3D"_blank" rel=3D"noreferrer">yaneurab= eya@gmail.com</a>> wrote:<br> >>><br> >>> Hello,<br> >>> One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL <br> >>> 3.0 into the base system. This is a must because, in short, Op= enSSL <br> >>> 1.1 is no longer supported as of 09/26/2023 [1].<br> >>><br> >>> I am proposing OpenSSL be made private along with all dependen= t <br> >>> libraries, for the following reasons:<br> >>> 1. More than a handful of core ports, e.g., security/py-crypto= graphy <br> >>> [2] [3], still do not support OpenSSL 3.0.<br> >>> i. If other dependent ports (like lang/python38, etc) move to = OpenSSL <br> >>> 3, the distributed modules would break on load due to clashing= <br> >>> symbols if the right mix of modules were dlopen=E2=80=99ed in = a specific <br> >>> order (importing ssl, then importing hazmat=E2=80=99s crypto w= ould fail).<br> >>> ii. Such ports should be deprecated/marked broken as I=E2=80= =99ve recommended <br> >>> on the 3.0 exp-run PR [4].<br> >>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes link= ing in <br> >>> both libraries at runtime impossible without resorting to a nu= mber of <br> >>> linker tricks hiding the namespaces using symbol prefixing of = public <br> >>> symbols, etc.<br> >>><br> >>> The libraries which would need to be made private are as follo= ws:<br> >>> - kerberos<br> >>> - libarchive<br> >>> - libbsnmp<br> >>> - libfetch [5]<br> >>> - libgeli<br> >>> - libldns<br> >>> - libmp<br> >>> - libradius<br> >>> - libunbound<br> >><br> >> In my opinion this is a huge amount of work a few weeks before the= <br> >> release.=C2=A0 Focusing on updating OpenSSL and those core ports m= ay be<br> >> simpler.<br> > <br> > This is my view.=C2=A0 I think making OpenSSL private is a very huge t= ask, and<br> > fraught with peril in ways that haven't been thought about yet (e.= g. PAM)<br> > and that we can't hold up OpenSSL 3 while we wait for this.=C2=A0 = Instead, I <br> > think<br> > we need to be moving forward with OpenSSL 3 in base as-is.=C2=A0 We wi= ll have to<br> > fix ports to work with OpenSSL 3 regardless (though this does make tha= t <br> > pain<br> > in ports happen sooner).=C2=A0 Moving libraries private can happen ort= hogonally<br> > with getting base to work with OpensSL 3.<br> <br> I have started to look at updating OpenSSL to version 3.0.8 in base, <br> using the existing vendor/openssl-3.0 branch.<br> <br> My progress can be found at <br> <a href=3D"https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0"= rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/khorben= /freebsd-src/tree/khorben/openssl-3.0</a>. I <br> regularly force-push to keep a consistent and nice commit history, <br> before possibly applying for a merge.<br> <br> So far the status is:<br> <br> - libssl, libcrypto build on amd64, i386, less sure about aarch64, other <b= r> architectures not tested<br> - libfetch builds, uses libmd in addition to OpenSSL<br> - libradius builds, same thing<br> - libarchive builds<br> - libunbound builds, but not unbound<br> - libmp builds<br> <br> I used libmd to reach a buildable status faster, since the equivalent <br> MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in <br> OpenSSL 3, we can avoid the dependency on libmd again. (anyone got <br> sample code for this?)<br> <br> Meanwhile I keep trying to build the rest of the system, hopefully in <br> time for a possible inclusion in -14.<br> <br> Reviews and tests on the whole thing will be more than welcome in any case!= <br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">= Cool. Id like to echo the namespace remapping suggestion.=C2=A0 OpenSSL ten= ds to be basically a leaf requirement.=C2=A0 If we always remapping our in = tree openssl, then if someone uses, say, libfetch and something else that r= equires openssl1, they can coexist in the same binary. Without the namespac= e remapping, we get a guaranteed conflict.</div><div dir=3D"auto"><br></div= ><div dir=3D"auto">It would increase our flexibility. And it could potentia= lly be mfc'd if the old openssl were left as an optional component for = people on stable stuck with it as a requirement. It would mitigate the EOL = issues while giving an escape hatch that's not insane (modulo the eleva= ted risk)</div><div dir=3D"auto"><br></div><div dir=3D"auto">I'll have = to take a closer look at the branch.=C2=A0</div><div dir=3D"auto"><br></div= ><div dir=3D"auto">Warner</div><div dir=3D"auto"><br></div><div dir=3D"auto= "><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Cheers & HTH,<br> -- <br> Pierre Pronchery<br> <br> <br> </blockquote></div></div></div> --000000000000e673af05fad287be--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr3a-QjWMco8UPvqD62d77StkWqAF%2BuJypc6Vi3jw8i1g>