Disable rustls's aws-lc-rs feature

[flip1995]

When both the ring and aws-lc-rs features in rustls are enabled, the rustls CryptoProvider installer from crate features no longer works, as the provider to be used is ambiguous 1.

This is the default configuration and feature set that other dependencies like reqwest are using.

[Narsil]

Sorry for the delay, but I fail to see the issue.

Is there any way we can reproduce the issue ?

Whatever the bug, I feel like it's a non fixable issue since the issue would arise with the other feature enabled. I think the solution provided in code is the solution, if both are specified, user needs to install the crypto provider manually (or the default). No ?
This is just how features work, they need to be able to be built with both enabled, right?

[flip1995]

I think the solution provided in code is the solution, if both are specified, user needs to install the crypto provider manually

Yes, this is basically the issue. All other crates in the ecosystem have their features set up in a way, that either the aws OR the ring provider is used and never both, depending on which features you set for those crates.

Let me describe the issue in a bit more detail:

rustls picks the provider automatically here, if either ring OR aws-lc-rs is set as a feature flag. If both features are active, it can't auto-select a provider and the user of any crate that depends on rustls (transitively) needs to select the provider. With the rustls default features enabled, aws-lc-rs is enabled as a provider.

Why is this a problem for hf-hub? Well, it isn't really your problem. But changing the rustls dependency, like I did in this PR, would make it fit better in the ecosystem.

As hf-hub with the rustls-tls feature

hf-hub/Cargo.toml

Line 46 in edda880

rustls-tls = ["dep:rustls", "reqwest/rustls-tls"]

chooses to use reqwest with the rustls-tls feature, hf-hub indirectly also chooses ring as a provider through the reqwest dependency. reqwest, hyper, tokio, ureq, ... are all setup, so that you can choose ring OR aws-lc-rs as a crypto provider through feature flags, or use (in the case of ureq) ring as the default provider w/o the option of picking aws-lc-rs.

So when hf-hub now enables the default features of rustls, while at the same time using reqwest as a dependency with ring as the provider, hf-hub forces all of its users to depend on both ring AND aws-lc-rs. This installs unnecessary dependencies for downstream users that only want to use ring, and forces them to specify a provider.

As the rustls only gets installed with the rustls-tls feature enabled, I think the best fix is to go the ureq route and choose ring as the provider.

---

To reproduce:

Using main branch of this repo:

$ cargo new hf-hub-dep-test
$ cd hf-hub-dep-test
$ cargo add --git https://github.com/huggingface/hf-hub --branch main --no-default-features --features rustls-tls,tokio,ureq
$ rg "aws-lc-rs" Cargo.lock
42:name = "aws-lc-rs"
1239: "aws-lc-rs",
1273: "aws-lc-rs",

Using the branch of this PR:

$ cargo new hf-hub-dep-test
$ cd hf-hub-dep-test
$ cargo add --git https://github.com/flip1995/hf-hub --branch rustls-features --no-default-features --features rustls-tls,tokio,ureq
$ rg "aws-lc-rs" Cargo.lock
# No output

[flip1995]

I also added back the dep:reqwest to the rustls-tls feature, as it didn't make sense to me not to depend on this crate in the rustls-tls case. LMK if I missed something.