Re: OpenSSL in the FreeBSD base system / FreeBSD 14

On Wed, 19 Apr 2023, Ed Maste wrote:

> There have been a few discussions on this topic in different venues,
> but we should consolidate the discussion on a public mailing list.
> This email represents a summary of the issues and the current state;
> we?ll discuss next steps in follow-up mail.
>
> FreeBSD 14 is coming soon, and one outstanding task is dealing with
> OpenSSL in the base system. The base system currently has OpenSSL
> 1.1.1, and it will be EOL as of 2023-09-11.
>
> There are two related issues:
>
> - The base system needs to migrate from OpenSSL 1.1.1.
> - The ports collection currently makes use of OpenSSL provided by the
> base system by default, with some exceptions.
>
> Changing the base system OpenSSL into a privatelib would decouple
> these two, so that the base system and ports can migrate to OpenSSL 3
> (or even to other implementations) on their own schedules. We have a
> number of privatelibs today, like libevent, that are used by the base
> system but not by ports. All OpenSSL-using ports will need
> security/openssl (or another openssl port).
>
> A related issue is base system libraries that depend on OpenSSL would
> also need to be made private. This includes gssapi, heimdal, and
> libfetch.
>
> This leaves the actual task of updating OpenSSL in the base system,
> which is complicated because we use bespoke build infrastructure in
> crypto/openssl/ rather than the upstream build bits. For better or
> worse this is the typical case for all of our contrib software, but
> OpenSSL is particularly tricky as it makes use of a large number of
> generated files, and those files are generated using Perl and perhaps
> other tools that are not available in the FreeBSD base system. Porting
> this to the base system is not insurmountable, but requires a fairly
> large amount of tedious work.
>
> This should serve as a snapshot of where we are today and a starting
> point for discussion; we?ll formulate a list of specific tasks in a
> follow-up.

Would the OpenSSL privatelib change mean that it's no longer possible to 
build and link base software against libs from ports given that those libs 
are linked to OpenSSL from ports then?

e.g. link base Sendmail (with OpenSSL privatelib) with libsasl from 
security/cyrus-sasl2 and libldap from net/openldap26-client which are then 
linked with libssl an libcrypto from security/openssl

or

link base Heimdal (with OpenSSL privatelib) with libldap from 
net/openldap26-client which is then linked with libssl an libcrypto 
from security/openssl

Both examples above are maybe not common but in use by myself since 
"ages".

If such setups will no longer work with OpenSSL privatelib and updating 
OpenSSL in base is such a complicated, heavy and time consuming task, one 
could ask - why use OpenSSL instead of one other SSL implementation in 
base at all?

This is not a rant against OpenSSL but if any other implementation 
provides the same as OpenSSL for base with a compatible license and an 
easier update path for the long term why not switch completely?
If it's then private in base (and of no use outside) anyway nobody 
outside base should care what it is.

Joerg

-- 
The beginning is the most important part of the work.
 				-Plato