feat(tls): make the rustls crypto provider selectable

[Greg Lamberson (glamberson)]

What

Make the rustls crypto provider selectable in ironrdp-tls. The rustls
feature pulled tokio-rustls with its default features, which forces the
aws-lc-rs provider on every downstream that selects the rustls backend.
tokio-rustls is now depended on with default-features = false and the
provider is chosen by a feature:

• rustls / rustls-aws-lc-rs: the aws-lc-rs provider. rustls is kept as
  an alias for rustls-aws-lc-rs, so the default backend and its resolved
  dependencies are unchanged.
• rustls-ring: the ring provider.
• rustls-no-provider: no provider is bundled; the downstream installs a
  rustls CryptoProvider as the process default before connecting.

No runtime code changes. The rustls backend already builds its config from
the process-default provider (ClientConfig::builder) and uses a
provider-agnostic certificate verifier, so only the feature definitions and
the backend cfg gate change. Cargo.lock is unchanged for the default build.

Why

A downstream RDP tool wants a pure-Rust TLS build (a RustCrypto provider) to
simplify cross-compilation, which is only possible if ironrdp-tls does not
force the aws-lc-rs provider. Making the provider selectable follows the
convention already used across the rustls ecosystem (reqwest, hyper-rustls,
tonic), which expose provider features and keep a default rather than imposing
one. The default stays aws-lc-rs.

Notes

This is provider build-shape selection, not gating of a protocol capability,
and the default behavior is preserved. cargo xtask check fmt/lints/tests/typos/locks
all pass. Happy to rename the features if you prefer a different convention.

[Benoît Cortier (CBenoit)]

Good idea. Thank you!

I would keep rustls feature, but deprecate it, and stop documenting it. I’m not blocking the PR on that though.

[Copilot]

Pull request overview

This PR makes the ironrdp-tls rustls backend’s crypto provider selectable at compile time by restructuring Cargo features, avoiding forcing a single provider onto downstreams via tokio-rustls default features.

Changes:

• Adds provider-selection features for rustls (rustls-aws-lc-rs, rustls-ring, rustls-no-provider) while keeping rustls as an alias for the default aws-lc-rs provider.
• Disables tokio-rustls default features to prevent implicitly selecting a provider for all downstreams.
• Updates crate docs and backend-selection compile-time checks to reflect provider selection.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
crates/ironrdp-tls/src/lib.rs	Updates rustls cfg-gating and backend-selection compile-time error messaging.
crates/ironrdp-tls/README.md	Documents rustls provider selection options and downstream expectations.
crates/ironrdp-tls/Cargo.toml	Restructures features to select the rustls crypto provider and disables tokio-rustls default features.

Comments suppressed due to low confidence (1)

crates/ironrdp-tls/src/lib.rs:8

• The rustls backend is currently cfg-gated on rustls-no-provider. Since rustls-no-provider is also enabled by the provider-selecting features, this works, but it makes the crate-level cfgs harder to interpret and couples the backend selection to a feature whose user-facing meaning is “no provider bundled”.

Gating on an explicit “any rustls backend” predicate (covering rustls, rustls-aws-lc-rs, rustls-ring, and rustls-no-provider) would make the intent clearer and reduces the risk of future feature-graph refactors accidentally breaking the cfg logic.

#[cfg(feature = "rustls-no-provider")]
#[path = "rustls.rs"]
mod impl_;

#[cfg(feature = "native-tls")]

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.