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

Enji Cooper <[email protected]> Tue, 2 May 2023 13:26:24 -0700
Newsgroups	gmane.os.freebsd.architechture
Message-ID	<[email protected]>
> On May 2, 2023, at 12:47 PM, Warner Losh <[email protected]> wrote:
> 
> On Tue, May 2, 2023 at 1:02 PM Cy Schubert <[email protected] <mailto:[email protected]>> wrote:
> On Tue, 2 May 2023 10:42:32 -0400
> Jung-uk Kim <[email protected]> wrote:

...

> Agreed. Making OpenSSL private doesn't mitigate the security risks.

(addressing this particular set of comments)

Some groups with deep pockets have paid extra $$$ to keep limited 1.x support alive for their internal use, so this is less of an issue for them, but it’s definitely an issue for the OSS community. Some groups also don’t have to deal with the technical and political issues blocking package upgrades (QEMU_EMULATING), so it’s easier to upgrade ports to versions that support OpenSSL 3; this unfortunately isn’t true for FreeBSD given the number of architectures and ports FreeBSD supports today.

Making libraries private makes it more possible for various versions of OpenSSL to coexist today with isolated components of a given system ($work doesn’t support `pkg` on customer sites, but we use it internally). This makes moving the codebase at $work iteratively from OpenSSL 1.x to OpenSSL 3.x easier from a practical/risk perspective. It doesn’t address the issue with shared process namespace introduced by PAM, python, and other applications that work via dlopen’ing openssl required libraries lazily, but it does solve a class of problem.

Adding FLAVORS support to ports could help address the other piece of this puzzle in ports and would simultaneously add a great deal of complexity to the package build matrix and dependencies as a whole (FLAVORS would technically have to deal with base, 1.1, 3.0, 3.1, libressl, bearssl, etc). This is something I considered and I would definitely in support of happening _with the idea in mind that someone with influence in the ports arena (I don’t have much in that arena) would need to make these changes._ I’ve been impeded enough when posting ports updates to support OpenSSL 3 in the python arena that I’ve given up hope with my being able to scale fixing all of the OpenSSL 3 related issues in ports [1]. I simply don’t have the bandwidth to setup the environment and do the necessary work to prove that what I’m doing won’t regress some form of package building within the FreeBSD support matrix [2].

I started the discussion to highlight the fact that (as of right now) the issues with OpenSSL 3 are less technical from a code uplift perspective in base, and more because of technical issues introduced by having ports rely on libraries being provided by the base system for legacy reasons. I think I succeeded in achieving that much, but there are some larger issues that need to be tackled first:

- What should be done about ports that don’t support OpenSSL 3 in the short-term and longterm?
- When should the switch be flipped from OpenSSL 1.x to 3.x in base?
- How will the FreeBSD project deal with OpenSSL 1.1 support on stable/ branches with ports when upstream projects (inevitably) start pulling OpenSSL 1.1 support from their projects [3]?

Thank you,
-Enji

1. FreeBSD ports updates are failure adverse instead of allowing for failures to occur and pivoting quickly to iteratively fix problems in ports.
2. FreeBSD doesn't have automated CI/CD for ports updates, so the responsibility falls on the submitter’s shoulders to verify their changes don’t break certain architectures, flavors, etc.
3. Keeping 1.1 support alive(ish) for stable/ is somewhat doable using the DEPRECATED macros, however, it doesn’t resolve all potential breaking issues when moving from 1.1 to 3.x.
signature.asc (application/pgp-signature, 833 B)