Date: Mon, 1 May 2023 22:47:16 -0500 From: "A. Wilcox" <AWilcox@Wilcox-Tech.com> To: 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: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> In-Reply-To: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com> References: <C6F8DD52-348E-42D8-84DE-B3A399D2606F@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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]. >=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-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 = specific order (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 = public 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 = additional 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 = solution I=E2=80=99m employing at $work requires. > I=E2=80=99ve tried to include some of the previously involved = parties so they can chime in. > Thank you, > -Enji >=20 > 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > 2. 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 QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 .=20 > 4. 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 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=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. Best, -A. -- A. Wilcox (they/them) SW Engineering: C/C++, DevOps, POSIX Wilcox Technologies Inc. --Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">On May 1, = 2023, at 8:55 PM, Enji Cooper <yaneurabeya@gmail.com> = wrote:<br><div><blockquote type=3D"cite">Hello,<br><div><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;"><div><div class=3D"content-isolator__container"><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: = after-white-space;"><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>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].</div><div><br></div><div><span class=3D"Apple-tab-span"= style=3D"white-space:pre"> </span>I am proposing OpenSSL be made = private along with all dependent libraries, for the following = reasons:</div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>1. More than a handful of = core ports, e.g., security/py-cryptography [2] [3], still do not support = OpenSSL 3.0.</div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>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 order = (importing ssl, then importing hazmat=E2=80=99s crypto would = fail).</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">= </span>i<font><span style=3D"caret-color: rgb(0, 0, = 0);">i. Such ports should be deprecated/marked broken as I=E2=80=99ve = recommended on the 3.0 exp-run PR [4].</span></font></div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>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.</div><div><br></div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>The = libraries which would need to be made private are as = follows:</div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>- kerberos</div><div><span = class=3D"Apple-tab-span" style=3D"caret-color: rgb(0, 0, 0); = white-space: pre;"> </span><span style=3D"caret-color: rgb(0, 0, = 0);">- libarchive</span></div><div><span style=3D"caret-color: rgb(0, 0, = 0);"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- = libbsnmp</span></div><div><span class=3D"Apple-tab-span" = style=3D"caret-color: rgb(0, 0, 0); white-space: pre;"> </span><span = style=3D"caret-color: rgb(0, 0, 0);">- </span><font><span = style=3D"caret-color: rgb(0, 0, 0);">libfetch = [5]</span></font></div><div><span class=3D"Apple-tab-span" = style=3D"caret-color: rgb(0, 0, 0); white-space: pre;"> </span><span = style=3D"caret-color: rgb(0, 0, 0);">- libgeli</span></div><div><span = class=3D"Apple-tab-span" style=3D"caret-color: rgb(0, 0, 0); = white-space: pre;"> </span><span style=3D"caret-color: rgb(0, 0, = 0);">- libldns</span></div><div><span style=3D"caret-color: rgb(0, 0, = 0);"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- = libmp</span></div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>- libradius</div><div><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>- = libunbound</div><div><br></div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>I realize I=E2=80=99m jumping to = a prescribed solution without additional 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 solution I=E2=80=99m employing at $work = requires.</div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>I=E2=80=99ve tried to include = some of the previously involved parties so they can chime = in.</div><div>Thank = you,</div><div>-Enji</div><div><br></div><div>1. <a = href=3D"https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/">https://w= ww.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/</a></div><div>2. <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853">https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853</a> .</div><div>= 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 QEMU builders due to missing emulation support: <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853">https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853</a> . </div= ><div>4. <a = href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15">ht= tps://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15</a></div><div= >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.</div></div></div></div></div></div></blockquote><br></div><div><br>= </div><div>Hi Enji (+ arch list),</div><div><br></div><div>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 with = known insecure software.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>-A.</div><div><br></div>-= -<br>A. Wilcox (they/them)<br>SW Engineering: C/C++, DevOps, = POSIX<br>Wilcox Technologies Inc.<div><br></div></body></html>= --Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89371295-EA1D-4C29-8690-C5C7BE96B178>