The hard requirement of `ring` feature on hyper-rustls causes conflicts

[rogusdev]

Is your feature request related to a problem? Please describe.

This:

async-stripe/async-stripe/Cargo.toml

Line 24 in 95b3e7b

hyper-rustls = { version = "0.27", default-features = false, features = ["http1", "http2", "tls12", "logging", "ring"], optional = true }

Leads to errors like this when using the more modern aws-lc-rs in other crates:

thread 'main' (28048) panicked at /home/chris/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustls-0.23.34/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.

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Other crates offer the option to choose one or the other (tho everyone is eventually moving to aws-lc-rs it seems like), but not this setup. It's probably very easy to add such a feature flag, with with a default on aws-lc-rs for hyper-rustls, instead of ring

Describe the solution you'd like

Use aws-lc-rs by default, with an option to override with ring

Describe alternatives you've considered

The workaround for me was to clone hyper-rustls and then modify its cargo.toml to do nothing with the ring feature, and include that in my project instead of an official version.

Additional context

I imagine you can repro this by adding this crate to a test app and then also adding -- if not then something like it:

rustls = { version = "0.23.34", default-features = false, features = ["aws-lc-rs", "std"] }

[arlyon]

Thanks for reporting / documenting. Keep track of all the mutex feature combinations of all our deps is a constant battle.

I will be happy to guide / review a PR if you have time to throw one together otherwise I will see if I can make some time in the near future. We probably need features on our side that conditionally enable one of those two crates. I am not sure whether we should make ring default or make users explicitly pick. I would probably prefer a default feature that enables ring that can be turned off / replaced.

[rogusdev]

I will see what I can do for a PR in the future. In the meantime, note that for both hyper-rustls and rustls, aws-lc-rs is the default, with ring being the optional feature to add:
https://docs.rs/crate/hyper-rustls/latest/features
https://docs.rs/crate/rustls/latest/features

[arlyon]

Ah, good to know. Seems like the default switched about a year ago.

algesten/ureq#751

[AnthonyMichaelTDM]

I also just ran into this, what are the workarounds?

[rogusdev]

I put this at the beginning of my main, to explicitly choose:

    rustls::crypto::aws_lc_rs::default_provider()
        .install_default()
        .expect("install aws-lc provider");

But I did have to do some work to get as many creates as possible not using ring (mostly all the AWS sdk creates I included).