Re: OpenSSL in the FreeBSD base system / FreeBSD 14

On Thu, 20 Apr 2023 14:46:08 -0400, Ed Maste <emaste@freebsd.org> wrote:

> On Thu, 20 Apr 2023 at 09:14, Joerg Pulz <Joerg.Pulz@frm2.tum.de> wrote:
>>
>> 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".
>
> Yes, I believe privatelib would preclude use cases like this.
>
> 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).
>
>> 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 a good question, and is something that's been discussed on
> occasion. The base system has some components that depend on OpenSSL
> right now. If we switch to privatelib it is quite possible that we'll
> migrate those to something else over time.

Due to the EOL of OpenSSL 1.1.1 I see only one "quick" solution for  
base - update base to the next OpenSSL LTS release 3.0 supported until  
7th September 2026. There is not that much time left for this task,  
right?

Ports incompatible with OpenSSL 3.0 will break anyway or is there a  
plan to keep the EOLed and then unsupported OpenSSL 1.1.1 in ports  
just to keep everything building? That would be a strange decision.

Shouldn't other vendors using OpenSSL (e.g. Linux distro's) suffer  
from the same situation - forced to update OpenSSL but third-party  
software/packages not ready for this?

IMO primarily upstream of the affected ports has to fix it's stuff to  
build against a supported (not EOLed) OpenSSL version.

Are there "exp-run for OpenSSL 3" results somewhere for an overview  
about all then broken ports?

I for myself would postpone the privatelib step to a later  
point/release (15?).
Early in the development phase for 15 there should be a discussion and  
decision about keeping OpenSSL at all in base or switch to something  
else better maintainable.

Joerg


-- 
Jörg Pulz
Gruppenleiter - IT Infrastruktur (bITTS)

Technische Universität München
Forschungs-Neutronenquelle Heinz Maier-Leibnitz (FRM II)

Lichtenbergstrasse 1
85748 Garching

Tel. +49 89 289 14708
Fax  +49 89 289 14666

Joerg.Pulz@frm2.tum.de
https://www.frm2.tum.de/