OpenSSL 1.1.1 EOL September 2023 - any advice on moving to OpenSSL 3.0?

[chrcol]

The issue is, this isn't possible without breaking ABI or having two different OpenSSL versions (one private) in base, which has other hard to solve issues. See also what Alexander wrote in the thread: https://lists.freebsd.org/archives/freebsd-arch/2023-April/000365.html -- I fully agree with him.

Now, this discussion was half a year ago. 14 already moved to OpenSSL 3 (before entering release engineering). A lot of fixing in ports was done as well, ports should largely build and work with OpenSSL 3 from base now.

I honestly don't know what's the plan now for stable/13. One could always try the "Debian approach" and backport security fixes yourself, which is very tedious and also error-prone work... not sure whether this is considered. People actively working on base probably know more.

From a user perspective, I'd say the best way to avoid this issue is to move to 14.0-RELEASE early on.

This I expected hence my comment, but the base is not the big issue as using 3.0 in ports will make almost everything on the server use 3.0 as dependency which is fine for me.

The bigger issue is that the move to 3.0 was left right to the last moment, this is inconsistent with how things are normally done when ports now days typically get bumped when a new upstream major version is released.

Is there a lot of breakages in the ports tree with openssl 3.0? for things like php 8.0, 8.1, dovecot, exim, apache, mysql, because if there is, it makes moving to 3.0 a no go which is the real problem.

But on 13.x if its deemed not possible to merge in openssl 3.0, then it might be an idea to drop openssl in base entirely, just pre install the port instead or back port security patches, more work for the dev's but I dont think is right to just say we will keep on building 13.x but dont use it and go to a point zero release instead. Thats my 5 pennies on that.

Also openssl 3.0 was released prior to FreeBSD 13.0, and at that point the openssl 1.1 EOL was published, so 13 should have been released with openssl 3.0 to avoid the problem, but I expect was no appetite back then to make sure the ports tree is working.

Seems they also waited 6 days after the quarterly ports tree update as well, that is 1.1 now until January.

 

[chrcol]

Only on development machines (servers) so far, but Apache, PHP/mod_php and MySQL (just built with OpenSSL 3 not knowingly using it) on amd64 13.2-RELEASE p4 - everything is building and seems happy with DEFAULT_VERSIONS+=ssl=openssl30 in /etc/make.conf.

Previously seen issues with vsftpd and libfido2 but the developers (thank you!) seem to have fixed those.

I'm not ready to try this on production and want to try a FreeBSD 14.0 install soon to compare against - but so far looking like it might fly (OpenSSL 3.0 on 13.2 using ports).

I got a machine which is supposed to be spare, a duplicate of a production machine, so I will snapshot it and try this week, but the issue is I do have a friend using email on there, so I have to be wary of that, and is hosting my secondary MX as well.

-- edit --

Wont be doing this until January as quarterly ports tree doesnt have it.

 

[msplsh]

The bigger issue is that the move to 3.0 was left right to the last moment, this is inconsistent with how things are normally done when ports now days typically get bumped when a new upstream major version is released.

I wouldn't expect a major upstream bump taking a few days. It's "major" for a reason. Penultimate paragraph in: https://www.freebsd.org/status/report-2023-04-2023-06/openssl3/

Only PHP 8.1+ uses OpenSSL 3.0 that was new in Nov 2021.

 

[zirias@]

Is there a lot of breakages in the ports tree with openssl 3.0?

Of course. The problem is no different from base here, OpenSSL-3 is a major API change (again!). There were tons of commits to ports for fixing related issues. This was actually another prerequisite for base moving to OpenSSL-3, because the default SSL implementation to use in a port is the one from base.

But on 13.x if its deemed not possible to merge in openssl 3.0, then it might be an idea to drop openssl in base entirely,

Unfortunately, no. libssl/libcrypto is a public shared library in base, and therefore part of the ABI. Just removing it would break the ABI just as well as upgrading it to 3.x, binaries linking it would stop working. ABI breakage is only allowed between major versions...

And then, removing it would create yet another problem: Quite some parts of base actually need SSL. You can't introduce a dependency from base to ports though, this would be pure chaos.

There's one somewhat similar idea to avoid this kind of issue in the future: Make OpenSSL in base "private" (so it can't be used by ports). Then it wouldn't be part of the ABI any more and could be upgraded any time. As a consequence, any port needing SSL would depend on some SSL implementation from ports. I'm not sure whether I like this idea, but it's certainly one possible solution....

 

[richardtoohey2]

First production server now on OpenSSL 3.0 and MySQL 8.0 - had to upgrade both because MySQL 5.7 won't build with OpenSSL 3.0.

So far so good (thanks developers!) - definitely a few things to watch out for with MySQL so would recommend you use a test system first. YMMV.

The inplace upgrade of MySQL from 5.7 to 8.0 seems to have gone without any issues (i.e. stop MySQL 5.7, deinstall, install MySQL 8.0 and start MySQL 8.0). There's no mysql_upgrade process any more. Database with many hundreds of tables, largest table with tens of millions of records, about 40G in mysqldump format.

All on 13.2, building from ports (to make sure everything built with OpenSSL 3.0).

 

[SirDice]

had to upgrade both because MySQL 5.7 won't build with OpenSSL 3.0.

Also worth noting that the MySQL 5.7 ports will be removed at the end of the year. So you need to upgrade to 8.0 (or some other database) anyway.

The inplace upgrade of MySQL from 5.7 to 8.0 seems to have gone without any issues (i.e. stop MySQL 5.7, deinstall, install MySQL 8.0 and start MySQL 8.0). There's no mysql_upgrade process any more. Database with many hundreds of tables, largest table with tens of millions of records, about 40G in mysqldump format.

There are a few things that need to be changed in my.cnf if you have them, see: https://forums.freebsd.org/threads/heads-up-mysql-default-version-will-switch-to-8-0.87917/

 

[SamKook]

There's a few packages that rely on dotnet 6 that won't work with 3.0 like emby and jellyfin so I'm stuck reverting to 1.1.1 until they update to dotnet 8.

 

[monwarez]

There's a few packages that rely on dotnet 6 that won't work with 3.0 like emby and jellyfin so I'm stuck reverting to 1.1.1 until they update to dotnet 8.

You should be able to use them in a separate jail running 13.x-RELEASE, then have a 14.0-RELEASE jail that do the reverse proxy and tls connection.
Of course you will need to upgrade the host to at least 14.0-RELEASE.