From nobody Tue May 02 03:47:16 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9Qyx3hSSz48PHH for ; Tue, 2 May 2023 03:48:09 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wilcox-tech.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9Qyx0BYWz4Fc8 for ; Tue, 2 May 2023 03:48:08 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 13731 invoked from network); 2 May 2023 03:48:20 -0000 Received: from ip98-188-99-66.tu.ok.cox.net (HELO smtpclient.apple) (AWilcox@Wilcox-Tech.com@98.188.99.66) by mail.wilcox-tech.com with ESMTPA; 2 May 2023 03:48:20 -0000 From: "A. Wilcox" Content-Type: multipart/alternative; boundary="Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2" List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) 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 Date: Mon, 1 May 2023 22:47:16 -0500 References: To: Enji Cooper , FreeBSD-arch list In-Reply-To: Message-Id: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Q9Qyx0BYWz4Fc8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --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 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 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].

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.

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 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

= 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 . 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--