Allow usage of ring instead of aws-lc-rs in tokio-rustls

[Leandros]

Feature Request

Motivation

To allow for not linking to aws-lc-rs (specifically, removing any usages of aws-lc-sys), I'd like to have the ability to chose the used provider from rustls.

Proposal

Tonic pulls in the tokio-rustls dependency, which defaults to use aws-lc as a cryptography primitive provider. However, tokio-rustls also ships with an alternative provider ring. To enable ring, the feature ring needs to be set (and the default features disabled).

To allow this with tonic, tonic would have to expose a new feature that allows choosing ring over aws-lc and forwards the feature flags to tokio-rustls.

Alternatives

Ideally, cargo would allow us to change features of dependencies of dependencies. However, at the current moment this isn't possible.

[mikemorris]

Has the direct ask here been resolved with #2034?

Somewhat related however, it would be nice if we could configure Tonic to optionally use alternative third-party providers, as discussed by @aumetra and @alexrudy in #1670 (comment)

[alexrudy]

It looks like #2034 does solve this? I'll take a deeper look though.

[alexrudy]

Confirmed, #2034 and others solve this, and it will be supported in the next release. I don't know when that will be, but maybe @LucioFranco we consider another release, since it's been several months (Sept. 2024, IIUC)?

At that point, there will be two tls features, tls-ring and tls-aws-lc-rs, which will do what you want respectively.

[LucioFranco]

Do we still want to do this if https://rustsec.org/advisories/RUSTSEC-2025-0007.html just was posted a few days ago?

[LucioFranco]

As for a release, I've been out of the country (away from the desk for the last few weeks and won't be back for another week and a half plus jetlag) so I was planning on getting a release out then since nothing seemed extremely high priority (though if there is please do ping me).

[aumetra]

The advisory was almost immediately retracted since the rustls team stepped up for basic maintenance without new feature development.

I feel like it still offers some smaller advantages, mainly in the way it compiles pretty easily in comparison to aws-lc-rs, but that's preference.

[TheButlah]

Yep, for me the main benefit is the easier compilation, especially cross compilation.

[LucioFranco]

The advisory was almost immediately retracted since the rustls team stepped up for basic maintenance without new feature development.

@aumetra do you have a link to this redaction I must have missed it but I am traveling (not for work) so maybe I missed it.

I literally see it on the rustsec page I linked 😂 hidden in plain sight

[youyuanwu]

Slightly off topic but I have seen more adoption of my project https://github.com/youyuanwu/tonic-tls to bypass ring recently.
I am willing to integrate/transfer it into tonic itself as a sub-crate, and I will keep maintaining it. Let me know.

[mikemorris]

Withdrawn advisory direct link for future reference https://rustsec.org/advisories/RUSTSEC-2025-0007.html

[mikemorris]

I think that cargo as of 1.60 has pretty good support for passing through features. I do think we should expose these features / backend control for TLS libraries.

@alexrudy Per your original pre-edited comment, is this something we should consider opening as a new issue? We have a specific interest in enabling alternative third-party providers (specifically to use an OpenSSL-based backend), and the approach you initially proposed seems like it could be promising even if you don't personally have bandwidth to take on exploration.

[LucioFranco]

Since this is fixed already in the master branch and a release will be going out this week, I will close this issue.

[LucioFranco]

Progress on the release can be tracked here #2135

[mikemorris]

@LucioFranco should I open a new issue to track the possibility of making passthrough config more flexible as described in #1943 (comment)?

[LucioFranco]

@mikemorris yeah that would be a good idea