How to use MySQL and rustls (i.e. do not use native-tls)

[oeed]

I'd like to avoid having native dependencies (including vendored native-tls) to make compilation and deployment significantly less complex (see this issue). Currently mysql_async depends on native-tls and libz-sys, with the optional feature of using rustls and rust-backend for flate2. native-tls is enabled on mysql_async by disabling default features and then adding the feature default-rustls.

However, I don't think this is possible to change for consumers of diesel_async currently. My understand of why this is the case is that features are additive, and thus I cannot tell mysql_async to turn off default features in my crate when diesel_async turns them on implicitly. If I'm wrong about this though I'd love to know how!

I've been trying the following:

[dependencies]
diesel = {version = "2.0.3"}
diesel-async = {version = "0.2.1", features = ["mysql"]}
mysql_async = {version = "*", features = ["default-rustls"], default-features = false}

But native-tls still appears in cargo tree.

There is #64 but that is Postgres specific. I'm not sure if this just due to limits in my understanding of cargo, or if it's not currently possible.

I created a fork which is working with no native depdendencies, which required the following toml changes:

- mysql_async = { version = ">=0.30.0,<0.32", optional = true}
+ mysql_async = { version = ">=0.31.0,<0.32", optional = true, features = ["rustls-tls"], default-features = false}
+ flate2 = { version = "*", default-features = false, features = ["rust_backend"] }
- mysql_common = {version = "0.29.0", optional = true}
+ mysql_common = {version = "0.29.0", optional = true, default-features = false, features = ["bigdecimal03", "rust_decimal", "time03", "uuid", "frunk"] }

[weiznich]

As you already noticed: Diesel-async currently depends on mysql_async with the default features enabled. I would happily accept a PR that disables the default features for mysql-async, as long as:

• Diesel-async continues to compile
• The PR contains some documentation (or an example) how to setup TLS support with various different solutions (which should be easily possible by just depending on diesel-async + mysql-async with the right feature flags then)

[oeed]

Unfortunately I do not think that'll work, at least without trade offs.

mysql_async depends on flate2 with default features off, but in order to compile, flate2 needs to compile with a backend feature enabled. With default features on mysql_async enables libz, which requires a native dependency.

Essentially we cannot allow crate consumers to directly specify their flate2 backend in their Cargo.toml while also having diesel_async compile with just the mysql feature. diesel_async needs to specify the flate2 backend in its Cargo.toml, if we pick rust_backend it'll compile fine and avoid a native dependency, but it means consumers' Cargo.toml files would be rather fiddly, as they'll need to list out every feature from mysql_async manually as defaults opt in to libz and it'd conflict.

[weiznich]

Hmm, given that facts I would be open to the following plan:

• Introduce a mysql-rustls and a mysql-native-tls flag in the short term (These should replace the existing mysql feature)
• Contact the developer of mysql_async and try to figure out a long term solution which makes it easier to configure that as down stream user.

[oeed]

Thanks, I have made an issue on mysql_async here and will PR those changes shortly.

[oeed]

Stemming from the above mysql_async issue, the default-rustls feature will be changed to avoid the dependency on libz which will make things significantly cleaner (just mysql_async/default-rust, not mysql_async/default).

Upon further reflection though, an alternate solution here could be to implement a mysql_backend feature used in cfg(feature ...) conditions, while the mysql feature just opts in to mysql_async/default and mysql_common/default. This would allow downstream users like myself to opt in to rustls as such:

diesel = {version = "..."}
diesel-async = {version = "...", features = ["mysql_backend"]}
mysql_async = { version = "*", default-features = false, features = ["default-rustls"]}

I also have no issue with the mysql-rustls and mysql-native-tls flags approach though, I'm just conscious of backwards compatibility issues with that solution.

[weiznich]

Given that the mysql_async maintainer is open to change the feature flags in that way, I would propose the following solution:

• diesel_async disables the default features + explicitly enables all non-ssl related default features for the existing mysql feature flag
• Users depending on diesel_async + the mysql backend are required to enable either the default-rustls or the default feature for mysql_async manually by depending on that crate.

This gives the user the required control, without diesel-async needing to expose all these feature flags. This change should contain some documentation regarding the required setup.

It's fine if that's a breaking change, as diesel-async has not reached a stable 1.0 version yet. We will bump the minor version for the next feature release anyway.

[mpiorowski]

@oeed Would You be so kind to share Your setup for the Mysql + Tls? I would like to compare it against mine and see if i can do something better.

pub async fn establish_connection_tls(database_url: &str) -> Result<Pool<AsyncMysqlConnection>> {
    let mgr = AsyncDieselConnectionManager::<AsyncMysqlConnection>::new_with_setup(
        database_url,
        create_tls_connection,
    );
    let pool = Pool::builder(mgr)
        .max_size(10)
        .build()
        .context("Error creating pool")?;
    Ok(pool)
}

fn create_tls_connection(database_url: &str) -> BoxFuture<ConnectionResult<AsyncMysqlConnection>> {
    let fut = async {
        let opts = mysql_async::Opts::from_url(database_url).map_err(|e| {
            diesel::ConnectionError::BadConnection(format!("Invalid database URL: {}", e))
        })?;
        let client = mysql_async::Conn::new(opts).await.map_err(|e| {
            diesel::ConnectionError::BadConnection(format!("Could not connect to database: {}", e))
        })?;
        AsyncMysqlConnection::try_from(client).await
    };
    fut.boxed()
}

[oeed]

Sorry for the late reply, I've been on leave. First it's important to note I'm using a forked version of diesel-async, that mightn't be needed anymore, but it was to get around the feature issues noted above. I was blocked by the mysql_async crate to actually make those changes the 'nice' way and PR here, but I'm not sure if that's still the case; will do so in the next month. The fork is here: https://github.com/oeed/diesel_async

Otherwise, I had fairly minimal changes on the actual connection setup really. These are the two functions I use (tweaked a little, removed running migrations, other abstractions, etc.), one for a single connection and another for pooled:

/// Create a database connection
pub async fn establish(url: &str) -> AsyncMysqlConnection {
  AsyncMysqlConnection::establish(url)
    .await
    .expect(&format!("Error connecting to database: {}", url))
}

/// Create a database pool
pub async fn establish_pool(url: &str, max_connections: usize) -> Result<Pool<AsyncMysqlConnection>, PoolError> {
  // create a new connection pool with the default config
  let config = AsyncDieselConnectionManager::<AsyncMysqlConnection>::new(url);
  let pool = Pool::builder(config)
    .runtime(Runtime::Tokio1)
    .create_timeout(Some(Duration::from_secs(10)))
    .max_size(max_connections)
    .build()
    .expect("Error creating database pool, bad builder config");

  Ok(pool)
}