Re: OpenSSL in the FreeBSD base system / FreeBSD 14

On 2023-04-19 9:50 AM, 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.

Personally I think it's not a very good idea to make base OpenSSL 
privatelib, because it would complicate things a lot (and think about 
when there is a SA for OpenSSL, the user would now have to build OpenSSL 
from port and base to patch their systems).  It is much slower to get a 
set of packages ready when libraries like OpenSSL, gettext, etc. gets an 
update, compared to applying a binary update to the base system.

However if we do go with the privatelib route, it's also an opportunity 
to explore other alternatives like LibreSSL (because we would have more 
flexibility on what we do with the base library).  Solving symbol 
conflicts should be possible but does incur an ongoing burden of 
maintenance, e.g. we could #define the exported symbols to have a 
prefix, like what was done for libmd, and the list of exported symbols 
can be extracted with nm(1).

Cheers,