Date: Tue, 2 May 2023 13:47:33 -0600 From: Warner Losh <imp@bsdimp.com> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Jung-uk Kim <jkim@freebsd.org>, 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: <CANCZdfrHsBotPYQsFUVoL6t%2BFVoXQZmNH7A3Ey=w3PBppsfOjw@mail.gmail.com> In-Reply-To: <20230502120200.32c545e4@cschubert.com> 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> <20230502120200.32c545e4@cschubert.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008ef52505fabb3621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2023 at 1:02=E2=80=AFPM Cy Schubert <Cy.Schubert@cschubert.c= om> wrote: > 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: > > >> 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, OpenSS= L > > >>>> 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-cryptograp= hy > > >>>> [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 specific o= rder > > >>>> (importing ssl, then importing hazmat=E2=80=99s crypto would fail)= . > > >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve > 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 publ= ic > > >>>> 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 add= itional > > >>>> discussion, but I=E2=80=99ve been doing offline analysis related t= o > 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 need= ed 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 solutio= ns > > >>>> that don=E2=80=99t have the degree of tunnel vision which the solu= tion I=E2=80=99m > > >>>> employing at $work requires. > > >>>> I=E2=80=99ve tried to include some of the previously involved part= ies 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>; . > > >>>> 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 Q= EMU > 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 > 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. > > >>> > > >>> > > >>> Hi Enji (+ arch list), > > >>> > > >>> My opinion may not amount to much, but I=E2=80=99m not sure it make= s 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 requir= e > > >>> 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/TL= S > > >>> implementation and perform experiments and innovate, then that seem= s > > >>> like it could be a useful tradeoff. However, if it=E2=80=99s just t= o 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 of= f > > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private librar= y > > > for OpenSSL in base might also simply the SSL framework in ports (?) > > > > > > Ren=C3=A9 (personal hat only) > > > > Please note upgrading OpenSSL and having private library are orthogonal > > issues. I do not disagree with the private library idea if it is > > upgraded and well maintained. I believe sweeping security > > vulnerabilities under the rug is a recipe for disaster. > > Agreed. Making OpenSSL private doesn't mitigate the security risks. > It limits the blast radius... But creates a new blast zone... > 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. > Yes. We don't want to be in a situation where we can't upgrade the base openssl because of excess port entanglement... Moving to private solves that problem... for base. > 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 > pB 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. > But does expose (I won't say create, because this issue is orthogonal to the openssl in base) an issue other projects are coping with, somehow. Warner > > > > Jung-uk Kim > > > > -- > 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 > > --0000000000008ef52505fabb3621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 2, 2023 at 1:02=E2=80=AFP= M Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com">Cy.Schubert@= cschubert.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">On Tue, 2 May 2023 10:42:32 -0400<br> Jung-uk Kim <jkim@FreeBSD.org> wrote:<br> <br> > On 23. 5. 2., Rene Ladan wrote:<br> > > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote:=C2= =A0 <br> > >> On 23. 5. 1., A. Wilcox wrote:=C2=A0 <br> > >>> On May 1, 2023, at 8:55 PM, Enji Cooper <<a href=3D"ma= ilto:yaneurabeya@gmail.com" target=3D"_blank">yaneurabeya@gmail.com</a>>= wrote:=C2=A0 <br> > >>>> Hello,<br> > >>>> One of the must-haves for 14.0-RELEASE is the introdu= ction of OpenSSL<br> > >>>> 3.0 into the base system. This is a must because, in = short, OpenSSL<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= dependent<br> > >>>> libraries, for the following reasons:<br> > >>>> 1. More than a handful=C2=A0of core ports, e.g., secu= rity/py-cryptography<br> > >>>> [2] [3], still do not support OpenSSL 3.0.<br> > >>>> i.=C2=A0If other dependent ports (like lang/python38,= etc) move to OpenSSL<br> > >>>> 3, the distributed modules would break on load due to= clashing symbols<br> > >>>> if the right mix of modules were dlopen=E2=80=99ed in= a specific order<br> > >>>> (importing ssl, then importing hazmat=E2=80=99s crypt= o would 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.=C2=A0OpenSSL 1.1 and 3.0 have clashing symbols, wh= ich makes linking in<br> > >>>> both libraries at runtime impossible without resortin= g to a number of<br> > >>>> linker tricks hiding the namespaces using symbol pref= ixing of public<br> > >>>> symbols, etc.<br> > >>>><br> > >>>> The libraries which would need to be made private are= as follows:<br> > >>>> - kerberos<br> > >>>> - libarchive<br> > >>>> - libbsnmp<br> > >>>> - libfetch [5]<br> > >>>> - libgeli<br> > >>>> - libldns<br> > >>>> - libmp<br> > >>>> - libradius<br> > >>>> - libunbound<br> > >>>><br> > >>>> I realize I=E2=80=99m jumping to a prescribed solutio= n without additional<br> > >>>> discussion, but I=E2=80=99ve been doing offline analy= sis related to uplifting<br> > >>>> code from OpenSSL 1.x to 3.x over the last several mo= nths and this is<br> > >>>> the general prescribed solution I=E2=80=99ve come to = which is needed for<br> > >>>> $work. My perspective might have some blind spots and= some of the<br> > >>>> discussion done over IRC and might need to be rehashe= d here for<br> > >>>> historical reference/to widen the discussion for alte= rnate solutions<br> > >>>> that don=E2=80=99t have the degree of tunnel vision w= hich the solution I=E2=80=99m<br> > >>>> employing at $work requires.<br> > >>>> I=E2=80=99ve tried to include some of the previously = involved parties so they<br> > >>>> can chime in.<br> > >>>> Thank you,<br> > >>>> -Enji<br> > >>>><br> > >>>> 1. <a href=3D"https://www.openssl.org/blog/blog/2023/= 03/28/1.1.1-EOL/" rel=3D"noreferrer" target=3D"_blank">https://www.openssl.= org/blog/blog/2023/03/28/1.1.1-EOL/</a><br> > >>>> <<a href=3D"https://www.openssl.org/blog/blog/2023= /03/28/1.1.1-EOL/" rel=3D"noreferrer" target=3D"_blank">https://www.openssl= .org/blog/blog/2023/03/28/1.1.1-EOL/</a>><br> > >>>> 2. <a href=3D"https://bugs.freebsd.org/bugzilla/show_= bug.cgi?id=3D254853" rel=3D"noreferrer" target=3D"_blank">https://bugs.free= bsd.org/bugzilla/show_bug.cgi?id=3D254853</a><br> > >>>> <<a href=3D"https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D254853" rel=3D"noreferrer" target=3D"_blank">https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853</a>>=C2=A0.<br> > >>>> 3. The reason why it hasn=E2=80=99t been upgraded is = because newer versions<br> > >>>> require rustc to build, which apparently doesn=E2=80= =99t work on QEMU builders<br> > >>>> due to missing emulation support:<br> > >>>> <a href=3D"https://bugs.freebsd.org/bugzilla/show_bug= .cgi?id=3D254853" rel=3D"noreferrer" target=3D"_blank">https://bugs.freebsd= .org/bugzilla/show_bug.cgi?id=3D254853</a><br> > >>>> <<a href=3D"https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D254853" rel=3D"noreferrer" target=3D"_blank">https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853</a>>=C2=A0.<br> > >>>> 4. <a href=3D"https://bugs.freebsd.org/bugzilla/show_= bug.cgi?id=3D258413#c15" rel=3D"noreferrer" target=3D"_blank">https://bugs.= freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15</a><br> > >>>> <<a href=3D"https://bugs.freebsd.org/bugzilla/show= _bug.cgi?id=3D258413#c15" rel=3D"noreferrer" target=3D"_blank">https://bugs= .freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15</a>><br> > >>>> 5. If I remember correctly, some folks suggested that= making libfetch<br> > >>>> private wasn=E2=80=99t required since the only port t= hat required it was<br> > >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this = claim.=C2=A0 <br> > >>><br> > >>><br> > >>> Hi Enji (+ arch list),<br> > >>><br> > >>> My opinion may not amount to much, but I=E2=80=99m not su= re it makes sense to<br> > >>> make it private solely for the sake of allowing ports to = keep going with<br> > >>> known insecure software.<br> > >>><br> > >>> I think ports should be loudly warning, right now, that t= hey require<br> > >>> OpenSSL 1.x and there should be work with both upstreams = and end users<br> > >>> to seek out and migrate to OpenSSL 3.=C2=A0 I, with other= s, have already<br> > >>> begun this work a while back in the Linux world.<br> > >>><br> > >>> If the desire is to make these libraries private for futu= re<br> > >>> improvements, or for the ability to swap in other another= crypto/TLS<br> > >>> implementation and perform experiments and innovate, then= that seems<br> > >>> like it could be a useful tradeoff. However, if it=E2=80= =99s just to allow<br> > >>> insecure software to continue to be used, I think that is= ill advised.<br> > >>>=C2=A0 =C2=A0=C2=A0The global landscape of information sec= urity is different and I think<br> > >>> it warrants a different response than maybe it would have= in the past.<br> > >>>=C2=A0 =C2=A0=C2=A0And it should at least be a considerati= on to have a loud and forceful<br> > >>> break in the interest of keeping data private and secure.= =C2=A0 <br> > >><br> > >> +1<br> > >><br> > >> Jung-uk Kim=C2=A0 <br> > > <br> > > (Randomly replying)<br> > > <br> > > Ports upstreams will probably take their time (if ever) to migrat= e off<br> > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private li= brary<br> > > for OpenSSL in base might also simply the SSL framework in ports = (?)<br> > > <br> > > Ren=C3=A9 (personal hat only)=C2=A0 <br> > <br> > Please note upgrading OpenSSL and having private library are orthogona= l <br> > issues.=C2=A0 I do not disagree with the private library idea if it is= <br> > upgraded and well maintained.=C2=A0 I believe sweeping security <br> > vulnerabilities under the rug is a recipe for disaster.<br> <br> Agreed. Making OpenSSL private doesn't mitigate the security risks.<br>= </blockquote><div><br></div><div>It limits the blast radius...=C2=A0 But cr= eates a new blast zone...</div><div>=C2=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> Making base OpenSSL private -- and subsequently krb5, as discussed many<br> moons ago -- avoids all kinds of ports issues with the same symbols,<br> some as functions with different arguments. It took a while to work<br> through the various MIT/Heimdal Kerberos conflicts and other issues.<br> The reason to make it private is to avoid difficult to resolve<br> conflicts with packages of the same name in ports.<br></blockquote><div><br= ></div><div>Yes. We don't want to be in a situation where we can't = upgrade the base</div><div>openssl because of excess port entanglement... M= oving to private</div><div>solves that problem... for base.</div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On the ports side, some ports will require OpenSSL 1.1.1 while others<br> will use 1.1.1 or 3.x. Package mutual exclusivity will affect users<br> wish to install package A with OpenSSL 1.1.1 prerequisite with package<br>p= B with OpenSSL 3.X prerequistite. The ports team may need different<br> flavors of various packages.<br> <br> The deeper we drill into this greater the number of landmines. This<br> might require a roadmap.<br></blockquote><div><br></div><div>But does expos= e (I won't say create, because this issue is orthogonal</div><div>to th= e openssl in base) an issue other projects are coping with, somehow.</div><= div><br></div><div>Warner</div><div>=C2=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> > <br> > Jung-uk Kim<br> <br> <br> <br> -- <br> Cheers,<br> Cy Schubert <<a href=3D"mailto:Cy.Schubert@cschubert.com" target=3D"_bla= nk">Cy.Schubert@cschubert.com</a>><br> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 <a href= =3D"https://FreeBSD.org" rel=3D"noreferrer" target=3D"_blank">https://FreeB= SD.org</a><br> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<a href=3D"mailto:cy@nwtim= e.org" target=3D"_blank">cy@nwtime.org</a>>=C2=A0 =C2=A0 Web:=C2=A0 <a h= ref=3D"https://nwtime.org" rel=3D"noreferrer" target=3D"_blank">https://nwt= ime.org</a><br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0<br> <br> </blockquote></div></div> --0000000000008ef52505fabb3621--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrHsBotPYQsFUVoL6t%2BFVoXQZmNH7A3Ey=w3PBppsfOjw>