Diesel MySQL backend not compatible with MariaDB Connector/C 3.4

[longsleep]

Setup

Versions

• Rust: 1.79.0
• Diesel: 2.2.0
• Database: MariaDB
• Debian 12 with MariaDB Connector/C 3.4

Feature Flags

• diesel: mysql

Problem Description

MariaDB Connector/C is an implementation of the MySQL Client library from MariaDB. It is used as drop-in replacement for the MySQL Client library for example on Debian and Ubuntu via the libmariadb-dev-compat package and offers a compatible C ABI.

Thus also Diesel via mysqlclient_sys does use the MariaDB Connector if it is installed as replacement for the MySQL client library.

This has worked for most purposes without any issue for MariaDB Connector/C <= 3.3.

Now with 3.4, Diesel fails to connect to the server with TLS/SSL error: SSL is required, but the server does not support it error message.

This is because for some reason, the MariaDB developers decided it is a good idea to ship with options.use_ssl=1 in mysql_init. Diesel is not aware of this (in

diesel/diesel/src/mysql/connection/raw.rs

Line 30 in f7e9819

let raw_connection = unsafe { ffi::mysql_init(ptr::null_mut()) };

) and hence the MariaDB client library will refuse to connect to anything without TLS.

Furthermore, the MariaDB Connector/C does not support MYSQL_OPT_SSL_MODE which is implemented by Diesel in

diesel/diesel/src/mysql/connection/raw.rs

Line 199 in f7e9819

fn set_ssl_mode(&self, ssl_mode: mysqlclient_sys::mysql_ssl_mode) {

which normally would be the way to enfore TLS.

The corresponding MariaDB ticket which as a result produced this change is at: https://jira.mariadb.org/browse/MDEV-31857?focusedCommentId=279904&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-279904

And the actual change is at: MariaDB/server@abcd23a#diff-b7189447363b2b74ee642549c398c1adcee11e2c8f4e0fa529dfde9d8f9e32faR1442

Thoughts

I am not sure what should be done about this. One way to solve the issue would be to simply add a line which sets options.use_ssl=0 after the call to mysql_init in Diesel code. That should restore the previous behavior.

MariaDB Connector/C and MySQL Client library have diverged in terms of "options" at least for TLS and the way how Diesel sets TLS options only works for the MySQL Client library - but not for the MariaDB Connector.

What is the actual output?

Diesel fails to connect, errors out with TLS/SSL error: SSL is required, but the server does not support it.

Steps to reproduce

To reproduce, use Debian 12, download the matching MariaDB-Connector C Connector 3.4.x release from https://mariadb.com/downloads/connectors/ and install it so that the shared library is actually used. One simple way to do this is via this script:

#!/bin/sh

set -ex

URL=https://dlm.mariadb.com/3907115/Connectors/c/connector-c-3.4.1/mariadb-connector-c-3.4.1-debian-bookworm-amd64.tar.gz

curl -sL ${URL} | sudo tar -C /usr/local -xzv --strip-components=1 \
    && sudo ln -snf /usr/local/lib/pkgconfig/libmariadb.pc /usr/local/lib/pkgconfig/mysqlclient.pc \
    && sudo ln -snf /usr/local/include/mariadb /usr/local/include/mysql \
    && pkg-config --variable=libdir libmariadb | sudo tee /etc/ld.so.conf.d/mariadb-connector-c.conf \
    && sudo ldconfig

Afterwards, use any Diesel program which uses the MySQL backend.

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

Can you explain why you believe that this is a bug in diesel and not just a change in libmariadb that is incompatible with your setup? I mean diesel does at no point guarantee a certain set of default settings there.
Also: The bug template is not optional. I suggest that you edit your bug report and add the relevant details.

Finally: Mariadb (including the client libraries) is something we do not officially support (yet, we still look for someone that implements and maintains an official backend). It's something that mostly works, but we do not guarantee anything there.

[longsleep]

You are right, this is not really a bug in Diesel in the sense that Diesel does something wrong. Though, there is something which Diesel could do to improve the situation and to avoid issues when the updated MariaDB Connector ends up in Debian/Ubuntu which then means Diesel cannot easily be used anymore.

So at the very least, it is now documented here that MariaDB Connector/C 3.4 does not work with Diesel's MySQL backend implementation, while previous versions have worked just fine.

This ticket also can serve as a debate if Diesel should simply set options.use_ssl=0 after retrieving the raw connection from mysql_init to maintain a certain level of compatibility at minimal cost.

[weiznich]

My problem with just setting options.use_ssl=0 is that I'm not sure how that behaves with the libmysqlclient (if it's even supported there) and how that influences setups that require ssl. If it's possible to restrict it to be used only libmariadb >= 3.4 and it does not prevent setting up SSL there I'm open to accept a PR for that. Otherwise I would appropriate a more complete approach to handle SSL setups with libmariadb correctly. Given that I neither use the mysql backend nor mariadb it's not a priority issue for me, so this needs to be done by some other contributor.

[longsleep]

I spent time investigating more. Turns out options.use_ssl=0 is not supported by libmysqlclient.

I encountered some confusion between the "internal MariaDB server client implementation" and the MariaDB Connector/C. The mysql_init function of the standalone library https://github.com/mariadb-corporation/mariadb-connector-c/blob/39f2e12f9a6640eb82f1974dcd0ab2bc296c1403/libmariadb/mariadb_lib.c#L1284 does not simply set options.use_ssl=1.

Instead starting with MariaDB Connector/C 3.4 MYSQL_OPT_SSL_VERIFY_SERVER_CERT is enabled by default which eventually results in the described problem at https://github.com/mariadb-corporation/mariadb-connector-c/blob/39f2e12f9a6640eb82f1974dcd0ab2bc296c1403/plugins/auth/my_auth.c#L320C36-L320C65 where it fails if the server does not provide an SSL connection.

The code where this is enabled by default compile time is at https://github.com/mariadb-corporation/mariadb-connector-c/blob/39f2e12f9a6640eb82f1974dcd0ab2bc296c1403/libmariadb/mariadb_lib.c#L718). The default value can be overwritten via options at https://github.com/mariadb-corporation/mariadb-connector-c/blob/39f2e12f9a6640eb82f1974dcd0ab2bc296c1403/libmariadb/mariadb_lib.c#L3586 (MYSQL_OPT_SSL_VERIFY_SERVER_CERT).

The option MYSQL_OPT_SSL_VERIFY_SERVER_CERT is supported by both MySQL and MariaDB client.

Unfortunately, at the moment Diesel does not seem to expose any means to set this connection option. It sems to be rather easy to extend

diesel/diesel/src/mysql/connection/url.rs

Line 44 in f7e9819

pub(super) struct ConnectionOptions {

though.

Update: while looking into this further I noticed that in MySQL the MYSQL_OPT_SSL_VERIFY_SERVER_CERT is deprecated and has been removed starting MySQL 8.0 (https://dev.mysql.com/doc/c-api/5.7/en/mysql-options.html)

MYSQL_OPT_SSL_VERIFY_SERVER_CERT (argument type: my_bool *)

Enable or disable verification of the server's Common Name identity in its certificate against the host name used when connecting to the server. The connection is rejected if there is a mismatch. For encrypted connections, this feature can be used to prevent man-in-the-middle attacks. Identity verification is disabled by default.

This option is deprecated as of MySQL 5.7.11 and is removed in MySQL 8.0. Instead, use MYSQL_OPT_SSL_MODE with a value of SSL_MODE_VERIFY_IDENTITY.

So, I guess that is a dead end either, since Diesel already supports to set SSL_MODE_VERIFY_IDENTITY but that is not supported by MariaDB.

[weiznich]

We could use something like MYSQL_VERSION_ID to guess which client version is used and afterwards set the relevant configs conditionally based on that. I would be open to accept a PR on that that conditionally sets options.use_ssl = 0 based on the provided ConnectionOptions. As far as I can see the relevant SSL information are already in there, right? That likely requires adding some methods to mysqlclient-sys that are implemented conditionally based on the mariadb/mysql version.

The other variant for this is to say libmariadb itself describes itself as:

It is used as drop-in replacement for the MySQL Client library for example on Debian and Ubuntu via the libmariadb-dev-compat package and offers a compatible C ABI.

If it is a drop in replacement the new behavior is a bug and should be fixed there. Have you considered raising it as bug in their issue tracker as well? This kind of suddenly diverging behavior makes it really hard to continue supporting both libraries.

[longsleep]

I might eventually come back to this. For now for us this means we continue shipping MariaDB Connector/C 3.3.

If it is a drop in replacement the new behavior is a bug and should be fixed there. Have you considered raising it as bug in their issue tracker as well? This kind of suddenly diverging behavior makes it really hard to continue supporting both libraries.

Yes it is like with all forks, eventually things will diverge and in this particular case the "drop-in replacement" is more a Debian thing than a MariaDB thing. It remains to be seen how this plays out when eventually it means that MariaDB and MySQL cannot be used interchangeably client side anymore (which more or less was the case since the start of MariaDB).

I would prefer if MariaDB client would simply implement the same options as MySQL client. Even if MariaDB would implement MYSQL_OPT_SSL_MODE option, that would be for a future version and not helping for their current 3.4 release.

Diesel could implement a runtime detection like you suggested and map the MYSQL_OPT_SSL_MODE to MariaDB specific code. But that would just offload complexity to Diesel which is not really a good thing.

I wonder, if - in the long run - client libraries need to have dedicated "MariaDB" support, which also would mean an mariadbclient-sys. Right now mysqlclient-sys seems to treat MariaDB as compatible, for example see sgrif/mysqlclient-sys@aa33adc - which is not entirely true.