Fix tls-with-tokio-rustls compilation

[utopiabound]

This allows this to compile when used as below:

kmip-protocol = { branch = "next", git = "https://github.com/NLnetLabs/kmip-protocol.git", default-features = false, features = ["tls-with-tokio-rustls"] } 

Otherwise both ring and aws-lc-rs are included by rustls and the binary dies with the following:

thread 'main' (43035) panicked at /opt/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.23.32/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.
See the documentation of the CryptoProvider type for more information.

[ximon18]

Hi @utopiabound,

I am probably missing something, it's been a while since I looked at this code, but if I try the following I don't seem to have a problem connecting:

$ gh pr checkout #46
$ cargo run --example demo --no-default-features --features tls-with-tokio-rustls -- --host google.com --port 443
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.57s
     Running `target/debug/examples/demo --host google.com --port 443`
[00:00:00.005] (7f880d103240) INFO   Querying server properties..

Would you perhaps be able to help me reproduce the issue?

Thanks,

Ximon

[utopiabound]

I don't have a simple reproducer, but without this change both ring and aws-lc-rs will be compiled into rustls which you can see via cargo tree in a crate that pulls in kmip_protocol.

Workaround for my code was to add this call in main():

    // Setup ring provider as default provider
    _ = tokio_rustls::rustls::crypto::ring::default_provider().install_default();

[ximon18]

I don't have a simple reproducer, but without this change both ring and aws-lc-rs will be compiled into rustls which you can see via cargo tree in a crate that pulls in kmip_protocol.

Workaround for my code was to add this call in main():

    // Setup ring provider as default provider
    _ = tokio_rustls::rustls::crypto::ring::default_provider().install_default();

The rustls docs say:

applications should call CryptoProvider::install_default() early in their fn main(). If applications uses a custom provider based on the one built-in, they can activate the custom-provider feature to ensure its usage.

Which seems to say your workaround is actually the right thing to do. I'm not sure that this library should make the choice of either ring or aws_lc_rs for you.

[utopiabound]

But it's not making the choice it's just not pulling in extra dependencies. The change just matches tokio-rustls features to the already specified rustls features.

[partim]

The question is why we pull in ring for rustls in the first place.

I think we can depend only on tokio-rustls with default-features = false and maybe add its optional features as our features?

[ximon18]

Hi @utopiabound,

My apologies for not responding sooner. Looking at how we pull in ring and use of features definitely makes sense to do.

We've been and still are quite busy on getting Cascade ready for production release. Once we're less busy with that we'll come back to looking at this crate (which Cascade uses via Cascade-HSM-Bridge).

Ximon

[partim]

PR #58 removes the default features for rustls and tokio-rustls. This means you have to specify the right rustls crypto feature when using the crate, which means you will have to add rustls as a dependency.

However, all of this is going to change in rustls 0.24, when you have to explicitly provide a crypto provider when creating a client or server. So we will have to change all sorts of things then, anyway. Hopefully, this will be already on the next branch.