OpenSSL 3.0.0 is now released as RC, so the design and functionality should not be changed any more: https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/

Can I kindly ask whether "Fix versions: 10.6" means somebody is looking at this soon or what is the rough ETA?

I've asked Sahana to update the copr repository https://copr.fedorainfracloud.org/coprs/saprasad/openssl-3.0/ with this newest release, so at last for fedora users, there would be a simple way to get the openssl 3.0.0 RC soon.

Is there anything else we can help with in order to make mariadb work fine with newer openssl? We can for example provide contacts to Red Hat colleagues from OpenSSL upstream if something needs to be discussed in more detail...

No, at the moment nobody is looking into it. But we'll do it, of course, we cannot ignore the new major OpenSSL version.

But it's not a simple task, we'll have to change the way MariaDB uses OpenSSL, it'll be a big refactoring.

The problem is that for a long time, since OpenSSL 0.9, the code heavily relied on various OpenSSL contexts allocated on the stack for one function only. Like create an MD5 context, calculate the hash, destroy the context. With OpenSSL making all objects opaque, we can no longer do it. And we don't want to replace all those stack allocations with malloc(), the server tries rather hard to avoid malloc(). So, we'll need to implement an approach that will work with opaque objects created by OpenSSL and still doesn't call malloc() every time we need to encrypt or hash something.

Do you think it makes sense to start with using deprecated functionality first (which is still available) and make it work with 3.0.0 at least somehow before doing it "correctly" without the deprecated functionality?

The patch I mentioned in the description makes the code compile this way, does not replace more than is necessary, and works find with many tests.. But it still does not address some other cases, mostly binlog_encryption suite fails (server crashes). It still seems quite doable without a big rewriting at least as the first step.

A simple (and faster) solution would be to reuse contexts. In current implementation every encryption or hashing operation creates a new context on stack and initializes it. Instead an existing context should be resetted (e.g. EVP_MD_CTX_reset) and reused.

After some more investigation, here is a short summary:

TLS protocol

• Remove DH param stuff and use SSL_CTX_set_dh_auto() instead (MDEV-26015)
• type of options parameter for SSL_CTX_set_options changed from long to uint64_t

Cryptography (Hashing and Encryption)

• Almost all Crypto API calls generate "deprecation" warnings, they need to be replaced by EVP_ functions.
• Reuse contexts for hashing and encryption: instead of allocating and freeing context we should reset handle (around 20% faster, maybe more if the same algorithm can be reused). This would also help to reduce memory allocations
• Preferrable also reduce the number of functions: my_sha(hashing_algorithm, data, len, digest) instead of single functions for each algorithm. Same is valid for encryption and decryption.
• Function EVP_CIPHER_CTX_buf_noconst (deprecated) needs to be replaced to detect overlapping bytes for non padding encryption.

Concerns/Possible problems

• WolfSSL doesn't seem to provide compatibility layer for OSSL 3.0
• We still have to support platforms which ship eoled OSSL versions (1.0.x)

Not much has to be changed for OpenSSL 3.0.
The "opacity" is of no concern. We already treat contexts as opaque. what's new, is that context have to be 16 bytes aligned, but we had seen it already with Wolfssl before. We have to guess the size of context, or we could see memory overwrites, but it is not really new either, we have been doing it for a while.

The biggest challenge in this version is broken EVP_CIPHER_CTX_buf_noconst, though I never found it to be documented.
The whole functional change (including suppressing the warnings) is some 30 lines of code
plus a little rework of aes-t code.

I notice the status is changed to "IN REVIEW", is the patch available now? Thanks!

I hope that before anything is pushed to main branches there is done some consideration and testing done that if server uses OpenSSL 3.0 Galera would also work (using OpenSSL x where x might not be same as 3.0 or where x = 3.0). See MDEV-25949 (at the moment I do not know if Galera library even compiles with OpenSSL 3.0). Remember that currently server and Galera library are build separately and there is no restriction to use older Galera library version than latest one i.e. for OpenSSL 3.0 if you can't use different versions we need to restrict also what Galera library version can be used.

I think this hope is unfounded, jplindst The server builds with OpenSSL, with or without -DWITH_WSREP. This work won't port Galera to OpenSSL 3.0. In case of negative outcome because of Galera, what should server do? Refuse to build does not make any sense, so either Galera works with OpeSSL 3.0, or we'll allow people who do not use Galera to use OpenSSL 3.0

The Server is not even aware Galera uses SSL or OpenSSL. Even if WSREP now spread over the entire codebase, Galera is logically, a plugin, which on whatever reasons, chose to build outside of the server.

Some questions:

• If server uses OpenSSL 3.0 can for example mysql client use OpenSSL 1.x or 2.x to connect ?
• If server uses OpenSSL < 3.0 can for example mysql client use OpenSSL 3.x to connect ?
• If both are true then what OpenSSL Galera uses is not relevant
• If they are false then we need to have both MDEVs done before feature is released

SSL is network level protocol, while OpenSSL 3.0 is a library implementing this protocol. Of course, different servers can be connected to different clients, as exemplified by Schannel , or GNUTLS, or OpenSSL, or for example Java clients successfully connecting to either OpenSSL, or to WolfSSL servers.

What OpenSSL Galera uses might be relevant, because it is not known (and Galera team will have to to find it out), whether 2 different OpenSSL libraries can coexist peacefully inside the same mariadbd process.

Mingli-Yu, on the right side of this page, at least in desktop JIRA variant click under "1 commit" , it will bring show you the commit (in colors!), and give the github link which is currently https://github.com/MariaDB/server/commit/c80991c79f701dac42c630af4bd39593b0c7efb4

I would just add one note from our OpenSSL team, which we got when we tried to implement the support ourselves (keep this just as heads-up).

Usage of MD5... How do you ensure that the legacy provider is loaded?

• OpenSSL 3.0 has a provider architecture and if you use, say, weak cipher algorithms (single DES, RC4) or hash algorithms (RIPEMD160), you need to ensure that the legacy provider is loaded.

If you already knew about this new change, just ignore this comment

I do not ensure it is loaded. It appears to work, as you can check by applying the patch.

Thanks Vladislav very much for your info!

pushed into preview-10.8-MDEV-25785-openssl3.0

I think preview-10.8-MDEV-25785-openssl3.0 as of 7cd965af can and should be pushed into the main 10.8 and released with 10.8.1. There are some limitations and can be a lot of unknowns, depending on the variety of environments and systems, which is why we need the community feedback.

Current status:

• Linux: The server and most plugins build with basic build configurations (RelWithDebInfo, Debug, mysql_release) on a variety of Linux versions. Checked: Ubuntu 18.04/20.04, Debian 9/10/11, SLES 12/15, RHEL 7/8, x86_64/aarch64; Ubuntu 20.04 ppc64le; OpenSSL 3.0.1, in-source build and build + local installation in custom location.
  • Limitations:
    • Columnstore does not build, MCOL-4964 to track;
    • A user should be careful with cmake options to make sure the custom OpenSSL 3 does not mix up with the default OpenSSL installation of a different version, MDEV-27540 to track (not directly related to this task)
• On Fedora Rawhide, where OpenSSL 3.0.0 is installed by default, the packages can be built and installed with it
  • Limitations:
    • Columnstore has to be disabled, MCOL-4962 (unrelated to this task) and MCOL-4964 to track;
    • If btrfs is in use, which is one of Rawhide's defaults, the server may not run. We are looking into it (unrelated to this task), meanwhile use XFS.
• On Windows, the server can be built and run with both OpenSSL 3.0.0 installed from slpro and with OpenSSL 3.0.1 built locally
  • Limitations:
    • For a local OpenSSL build, installation must be performed (nmake install). With an in-source build, MariaDB server will compile/link, but will issue runtime errors (probably has always been so, and various README notes also suggest installation).

• CI: There is a Ubuntu 20.04-based buildbot builder which currently builds the server with a local OpenSSL 3.0.1 installation, and there will soon be a Rawhide-based builder which will run RPM builds with the system-wide OpenSSL 3.

Other notes:

• There are a few binaries/plugins which still link with OpenSSL 1.x, whether legitimately or not, it is being looked into (MDEV-27542)
• I didn't manage to build deb packages with OpenSSL 3.0 yet, there are some configuration issues to work around. It shouldn't be important for initial adoption though.

elenst Codership reported earlier that Galera library will build with OpenSSL 3.0 but I have not tested (MDEV-25949 ).

Galera library is obviously out of this server task, it was also stated in advance in this comment.
I did run .*ssl.* MTR tests as a part of the Linux exercise, including tests in the galera suite with an existing galera-4 library, on a server linked with openssl3, they passed. This is as much as I can say about the current Galera status.