Re: OpenSSL in the FreeBSD base system / FreeBSD 14

On 2023-04-24 7:49 AM, Dimitry Andric wrote:
> On 24 Apr 2023, at 16:39, Warner Losh <imp@bsdimp.com> wrote:
>>
>> On Mon, Apr 24, 2023, 8:33 AM Charlie Li <vishwin@freebsd.org> wrote:
>> Ed Maste wrote:
>>> The problem is that we have conflicting constraints: OpenSSL 1.1.1 is
>>> EOL shortly after 14.0 releases, and there are ports that do not yet
>>> build against OpenSSL 3. I am not sure how much will be broken if we
>>> update the base system to OpenSSL 3 but leave the privatelib aside
>>> (i.e., have the base system provide OpenSSL 3 to ports).
>>>
>> OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a bit
>> of stuff will be broken today. The effort here has to include working
>> with as many port upstreams as possible to force the issue, as they may
>> not hold OpenSSL 3 compatibility to be an immediate priority; patching
>> ports on a large scale like this is not sustainable.
>>
>> So why can't ports like this use 1.1 as a port rather than from base?
> 
> Trouble starts when you attempt to mix openssl 1.1 and 3.0 libraries
> (both dynamic and static!) in dependent ports, because symbol names will
> collide.
> 
> This is not an easily solvable problem, apart from the fact that an
> openssl 1.1 port would have the same basic issue that openssl 1.1 in the
> base system has: it will no longer be supported (at least without paying
> up) after $CUTOFF_DATE.


(Disclaimer: I'm not a big fan of making OpenSSL a private library, but 
I think it should be possible to do it if we want to...)

I think we create a separate header file (e.g. 
private_openssl_namespace.c) which mechanically #define's all exported 
symbols to something unique and do not collide with OpenSSL, like what's 
done for libmd.  (and the header can be generated by parsing the nm -D 
output of the OpenSSL libraries)

Cheers,