Allow consumers to remove the `ring` transitive dependency

[punya]

Title

Allow consumers to remove the ring transitive dependency

Summary

Rerun currently forces a transitive dependency on ring onto anyone who depends on the viewer or SDK crates.
It would be good to make ring optional / overridable, so that consumers who prefer a different cryptography backend (most commonly aws-lc-rs) can avoid pulling ring into their build at all.

Motivation

The rustls project no longer treats ring as the recommended default cryptography provider — as of rustls 0.23 the default is aws-lc-rs, and ring is only used when explicitly opted into via the ring crate feature.

While Rustls itself is platform independent, by default it uses aws-lc-rs for implementing the cryptography in TLS.

— rustls crate docs, https://docs.rs/rustls/latest/rustls/ (the ring provider is described as available only "with the ring crate feature enabled").

Consumers embedding Rerun in a larger application often already standardize on aws-lc-rs (or a specific FIPS-validated / audited crypto backend) and want a single crypto provider across their dependency tree.
Today Rerun makes that impossible: ring is unconditionally dragged in, so these consumers end up with two crypto backends compiled in, or cannot satisfy their own supply-chain / crypto-policy requirements.

Where ring enters Rerun's dependency graph

There are two independent entry points:

1. re_auth (oauth feature) uses ring::signature directly for RS256 JWT verification.

   • crates/utils/re_auth/Cargo.toml: ring = { workspace = true, optional = true }, gated behind the oauth feature.
   • crates/utils/re_auth/src/crypto_provider.rs: use ring::signature as ring_sig; (RSA PKCS#1 SHA-256 verification).
   • This is the dominant path: re_auth → re_perf_telemetry → re_datafusion → … → re_viewer → rerun, so essentially the whole viewer graph inherits ring.

2. rerun_py selects ring as the rustls crypto provider.

   • rerun_py/Cargo.toml: rustls = { workspace = true, features = ["ring"] }.

(For reference, the workspace already pins rustls = { version = "0.23.40", default-features = false } and ring = "0.17.14" in the root Cargo.toml, and reqwest is configured with rustls-tls.)

Possible implementations

Listed roughly from "most flexible for consumers" to "simplest":

1. Force the consumer to choose the crypto provider.
   Expose no default crypto backend from the crates that need one; require the downstream application to install a rustls CryptoProvider and to supply the RSA-verification backend for re_auth.
   Most flexible and most explicit, but the biggest breaking change and the most friction for simple consumers / examples.

2. Depend on ring by default, but allow it to be overridden (cfg / Cargo features).
   Keep the current behavior out of the box, but add mutually-exclusive features (e.g. crypto-ring vs crypto-aws-lc-rs) on re_auth (and a matching knob for the rerun_py/rustls selection) so a consumer can turn ring off and select aws-lc-rs instead.
   For re_auth's RS256 path this means abstracting the RSA verification behind a small trait or feature-gated module rather than calling ring::signature directly.
   Non-breaking default, opt-in migration path.

3. Switch to aws-lc-rs.
   Replace ring with aws-lc-rs outright (both the rustls provider feature and the re_auth RS256 verification).
   Simplest end state and aligns with rustls' current default, but aws-lc-rs has a C/build-toolchain (cmake/NASM) footprint that may be undesirable for some targets (notably wasm and some cross-compilation setups), so it may need to remain feature-selectable anyway.

Notes / open questions

• Any solution needs to cover both entry points above, not just the rustls feature — otherwise re_auth's direct ring::signature use keeps ring in the tree.
• wasm builds and cross-compilation should be considered when picking between ring and aws-lc-rs, since their C-toolchain requirements differ.
• A feature-based approach (option 2) is likely the least disruptive first step and can coexist with a longer-term move toward option 3.

[grtlr]

Thank you for pointing this out!

We currently use ring because it is still the default for many crates in the Rust ecosystem, even if rustls has changed. It also has a simpler build (no cmake).

That being said, it looks like aws-lc-rs is gaining momentum, so I think we'd be fine with the feature flags from option 2, if we receive a PR that implements that and

• still keeps ring as default for now
• keeps the dependency tree clean (no unnecessary duplicates)
• works with our CI on all platforms