Re: OpenSSL in the FreeBSD base system / FreeBSD 14

Quoting Charlie Li <vishwin@freebsd.org> (from Mon, 24 Apr 2023  
10:33:39 -0400):

> 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.

OpenSSL is a major part of the security infrastructure worldwide. Once  
1.1.1 is EOL, it is "burnt" and should not be used anymore. Any 0-day  
exploit will cause havoc and software would need to be switched to 3.x  
before that if you take it seriously.

So from a security perspective, I rather switch now (while 14.0 is  
still called -current instead of -rc or -stable) to 3.x and live with  
the collateral damage in ports, which will naturally get smaller over  
time as people have more pressure to fix it soon to get something they  
need get up and running.

 From a stability point of view, this is off course a bad way of handling it.

As -current is not -stable, I could imagine a split view on this:
  - announce to -stable users to switch to the quarterly branch for a while
  - warn -current users about collateral damage for a while (e.g.  
UPDATING entry in src and ports)
  - switch -current to 3.x (quick and easy, not as a private lib)
  - let port maintainers and users work together on fixes for the  
broken ports (in each port: if OSVERSION >= 14000x use 3.x patch) ...
  - ... while work is underway to switch openssl to a private lib in -current.

Maybe also halt the package distribution to the official download  
sites while the main branch of the ports tree has too much collateral  
damage, and resume it once "enough" ports build.

That's maybe not nice, but at least something which a volunteer  
project is able to handle. It divides the problem into smaller pieces  
which can be worked on in parallel.

For 13-stable I consider the train to have already left the station.  
We can not fix existing releases to use openssl 3.x in parallel to the  
existing 1.1.1 libs. Anything we do to ports to use openssl 3.x, no  
matter if as a private lib in base or not, has to be gated with  
OSVERSION conditionals. As such 13.x is a train wreck from a security  
perspective as soon as openssl is EOL and IMO we need to highlight in  
the release notes in 14.0 that it is highly recommended to switch to  
it as soon as possible.


My main point is, that we can not only look at 14.0, but we need to  
have a look at the big picture, including 13.x and the global security  
implications. And from my point of view, we (as a volunteer effort)  
are not able to deliver a solution which works for the entire big  
picture. We have to accept some kind of collateral damage in the big  
picture. And my suggestion is to think about which collateral damage  
we are willing to accept. The above is one way of accepting a  
particular collateral damage. There are other scenarious which have  
different kinds of collateral damage, and as a project we need to  
decide which one we are willing to accept, we need to realistically  
think about which one we able to work on (and personally I would value  
the voice of those people which will provide a halping hand a bit  
higher than the opinion of others).

I agree that ideally all upstreams have to be included, but if we are  
realistic, it means we fix our stuff and provide patches to upstream,  
and some of those may even be included upstream (yes, there are off  
course also upstreams which will do the right thing, but we can not  
depend on this on a global scale).

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF