rustls: dual-provider tree (ring + aws-lc-rs) has no process-level CryptoProvider default — panics on the VSS TLS path

[hash-money]

Context: @tnull asked us to split this out of lightningdevkit/orange-sdk#90 (comment: "Can you expand on that and maybe open a separate issue for it? LDK Node should do that for you, so we should investigate what's going on exactly."). Filing here per that request — and flagging honestly below where the trigger actually lives, in case you conclude it belongs in bitreq/corepc instead.

Symptom

When a binary embedding ldk-node compiles both rustls crypto providers — aws-lc-rs (rustls' default) and ring — rustls has no unambiguous process-level default, so any code that builds a ClientConfig via the process-default-dependent ClientConfig::builder() panics:

thread 'main' panicked at rustls-0.23.37/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.

Reproduced standalone to isolate it to rustls itself (v0.23.37, our pin):

rustls = { version = "=0.23.37", features = ["ring"] }   # default features also bring in aws-lc-rs

fn main() { let _ = rustls::ClientConfig::builder(); }    // panics as above

Where the two providers come from (our tree)

• ring — pulled in by electrum-client (our chain source, under ldk-node).
• aws-lc-rs — rustls' default, on the VSS / HTTP path.

ldk-node is where these two meet in a single process, which is why the collision surfaces at wallet init rather than in either dependency alone.

Where it triggers today

We hit this while integrating rust-bitcoin/corepc#661 — the bitreq connection-persistence fix you and @TheBlueMatt asked us to benchmark on #90. The patched bitreq builds its rustls ClientConfig from the process-level default, so with both providers present it panics at the first VSS request.

On the released stack (without corepc#661) we do not hit it — nothing on that path calls the process-default builder — so today it's latent, and gets exposed by the very patch that fixes the VSS latency. That's the part worth investigating: the perf fix and this panic arrive together.

Our workaround (the shim referenced on #90)

At wallet init, before any TLS client is constructed:

// tree unions `ring` (electrum-client) + `aws-lc-rs` (rustls default) — ambiguous,
// so select one explicitly. Idempotent; the Err on a second call is expected.
let _ = rustls::crypto::aws_lc_rs::default_provider().install_default();

It works, but install_default() makes a process-global choice from library/app init — the decision rustls says the top-level binary should own. Pushing that onto every downstream app embedding ldk-node is the awkward part.

Fix direction (deferring to you on the right layer)

Rather than depend on the process-level default, the code that builds these ClientConfigs (ldk-node's own TLS clients, or bitreq's) could construct them with an explicit provider via ClientConfig::builder_with_provider(...), so a multi-provider tree neither panics nor forces downstream to install a process-global default.

If you conclude the right place is bitreq, we're glad to carry this straight to corepc#661 — we just surfaced it here per your request, since ldk-node is where the two providers collide.

Repro / standing offer

The standalone snippet above pins the panic to rustls. Our full-stack capture (A12 device + desktop wallet-cli against staging VSS) is scripted — point us at a branch and we'll confirm the panic is gone, before/after, same as we've done for #93 / #94 / corepc#661.