From nobody Tue May 02 13:42:22 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 4Q9h8q0bMmz490tX for ; Tue, 2 May 2023 13:42:35 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9h8n3y2Yz41pl for ; Tue, 2 May 2023 13:42:33 +0000 (UTC) (envelope-from crest@rlwinm.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de; dmarc=none Received: from [192.168.178.53] (119-101-142-46.pool.kielnet.net [46.142.101.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id C3FA822B7D for ; Tue, 2 May 2023 13:42:23 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------dssLZMj1Lmz3aVd33p91GgL3" Message-ID: Date: Tue, 2 May 2023 15:42:22 +0200 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.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 To: freebsd-arch@freebsd.org References: Content-Language: en-US From: Jan Bramkamp In-Reply-To: X-Spamd-Result: default: False [-0.85 / 15.00]; NEURAL_HAM_SHORT(-0.79)[-0.793]; NEURAL_SPAM_LONG(0.77)[0.775]; NEURAL_HAM_MEDIUM(-0.53)[-0.531]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[rlwinm.de]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Q9h8n3y2Yz41pl X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------dssLZMj1Lmz3aVd33p91GgL3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02.05.23 03:55, 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]. > > 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’ed in a specific order > (importing ssl, then importing hazmat’s crypto would fail). > ii. Such ports should be deprecated/marked broken as I’ve 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 How does this interact with PAM and NSS? According to my understanding both PAM and NSS work by loading modules as shared libs into the process using them. As a quick test I ran ldd against the PAM modules included in the FreeBSD 13.2 base system and found a lot of them (pam_krb5, pam_ksu, pam_passwdqc, pam_radius, pam_ssh, pam_unix and pam_zfs_key) depend on the base system OpenSSL. Almost all PAM configurations will (try to) used at least one of these modules. As far as I can tell the NSS "modules" available in base are all implemented by libc and don't load the base OpenSSL (at runtime). The same problem would also apply in the reverse direction with PAM and NSS modules loading OpenSSL from ports into services included in base using the base OpenSSL (e.g. sshd). Are there other mechanisms to watch out for that combine shared libs from base and ports at runtime? Are there maintainable solutions in both directions? --------------dssLZMj1Lmz3aVd33p91GgL3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 02.05.23 03:55, 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].

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’ed in a specific order (importing ssl, then importing hazmat’s crypto would fail).
ii. Such ports should be deprecated/marked broken as I’ve 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

How does this interact with PAM and NSS? According to my understanding both PAM and NSS work by loading modules as shared libs into the process using them.

As a quick test I ran ldd against the PAM modules included in the FreeBSD 13.2 base system and found a lot of them (pam_krb5, pam_ksu, pam_passwdqc, pam_radius, pam_ssh, pam_unix and pam_zfs_key) depend on the base system OpenSSL. Almost all PAM configurations will (try to) used at least one of these modules. As far as I can tell the NSS "modules" available in base are all implemented by libc and don't load the base OpenSSL (at runtime).

The same problem would also apply in the reverse direction with PAM and NSS modules loading OpenSSL from ports into services included in base using the base OpenSSL (e.g. sshd).

Are there other mechanisms to watch out for that combine shared libs from base and ports at runtime? Are there maintainable solutions in both directions?

--------------dssLZMj1Lmz3aVd33p91GgL3--