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

Activity

1. big14way commented on Aug 30, 2026

   

   big14way

   on Aug 30, 2026

   More actions

   @hash-money dug into this on main. The root cause isn't quite where the report puts it, and there's a second bug.

   aws-lc-rs comes from chain-electrum, not the VSS/HTTP path. cargo tree -e no-dev with chain-electrum off: rustls v0.23.43 feats=ring,std,tls12, and no aws-lc-rs in the tree at all. With it on: feats=aws-lc-rs,aws_lc_rs,default,log,logging,prefer-post-quantum,ring,std,tls12. bitreq (the VSS/HTTP path) asks only for ["ring","std","tls12"].

   electrum-client 0.25 has an optional dep rustls and a same-named feature rustls = ["webpki-roots","dep:rustls","rustls/default"]. The explicit feature shadows the implicit one, so rustls-ring's "rustls/ring" also enables the rustls feature → rustls/default → aws-lc-rs. The resolved tree shows electrum-client feats=…,rustls,rustls-ring,use-rustls-ring,… even though bdk_electrum and lightning-transaction-sync both pin default-features = false (note default is absent from that list). So 4b45d7c ("Switch to use rustls-ring everywhere") never actually produced the ring-only tree it advertises — which matters for the step 2 @tnull sketched in #600.

   The safeguard runs after the first TLS request on the VSS path. optionally_install_rustls_cryptoprovider() is called in build_with_store_internal (builder.rs:1494), but all four build_with_vss_store* methods construct the store first (builder.rs:803, 841, 869, 895). VssStore::new does a blocking determine_and_write_schema_version on a scoped thread (io/vss_store.rs:128-143 → :810), and vss-client-ng → bitreq builds its ClientConfig from the process default. No corepc#661 needed — this is reachable on the current pin against an https:// VSS URL. The scoped-thread join() catches the unwind and turns it into BuildError::KVStoreSetupFailed, so it surfaces as a confusing setup failure rather than the rustls message; under panic = "abort" profiles it aborts.

   Happy to take: hoist the install ahead of VSS store construction, declare rustls's ring feature explicitly in our own manifest (builder.rs:2508 calls rustls::crypto::ring::default_provider(), but Cargo.toml:108 declares rustls with default-features = false and no features, so that only compiles because something else in the tree turns ring on), and carry the manifest fix upstream to electrum-client — renaming the dep to rustls_dep = { package = "rustls" } removes the shadowing and yields rustls feats=ring,std,tls12.

   Do you want provider choice behind tls-ring/tls-aws-lc-rs features, along the lines of what @TheBlueMatt described on #600, or keep a single pinned provider?
2. hash-money commented on Aug 30, 2026

   

   hash-money

   on Aug 30, 2026

   Author

   More actions

   @big14way thanks — we re-derived all of this independently and it holds. Corrections to our own report first, then the one thing you may not have seen, then your question.

   Confirmed (cargo tree on main 6480bff):

   # default features
   rustls v0.23.43 feats=aws-lc-rs,aws_lc_rs,default,log,logging,prefer-post-quantum,ring,std,tls12
   electrum-client v0.25.0 feats=byteorder,libc,proxy,rustls,rustls-ring,use-rustls-ring,webpki-roots,winapi
   
   # --no-default-features --features chain-esplora,chain-bitcoind,storage-sqlite,storage-filesystem,storage-vss,unified-payments
   rustls v0.23.43 feats=ring,std,tls12        # no aws-lc-rs in the tree
   

   Minimal repro of the shadowing, one dependency only: electrum-client = { version = "=0.25.0", default-features = false, features = ["use-rustls-ring"] } resolves rustls with aws-lc-rs,…,default,…,ring; the same crate with rustls-ring = [..., "rustls?/ring", "rustls?/logging", "rustls?/std", "rustls?/tls12"] resolves rustls feats=log,logging,ring,std,tls12.

   Ordering: read as you describe — build_with_vss_store (builder.rs:797–809) runs VssStoreBuilder::build_with_sigs_auth → VssStore::new → the scoped-thread determine_and_write_schema_version (io/vss_store.rs:128–143) before build_with_store_internal reaches optionally_install_rustls_cryptoprovider() (:1494); the join() error becomes KVStoreSetupFailed (:805). One nuance: the rustls panic text still reaches stderr through the default panic hook — it's only the returned BuildError that loses it. We have not executed this path on main; see the offer below.

   Two corrections to the opening report:

   1. The aws-lc-rs attribution was wrong. It is not "rustls' default on the VSS/HTTP path" — in our tree, exactly as in yours, the only source is electrum-client's rustls feature leaking rustls/default. Substituting the rustls?/… manifest (and no default features on our own rustls dep) leaves our Android target at rustls feats=log,logging,ring,std,tls12 — aws-lc-rs gone entirely.
   2. "The released stack doesn't hit it" was a lockfile artifact, not a property of the code. Our Cargo.lock holds bitreq 0.3.4, which is on rustls 0.21 (no CryptoProvider concept). bitreq ≥ 0.3.5 requires rustls ^0.23.38, and 0.3.7 — what a fresh resolve of main's bitreq = "0.3" gets — builds its config with ClientConfig::builder() (connection/rustls_stream.rs:36–50). So corepc#661 was incidental: it was simply the first rustls-0.23 bitreq we ran. No patch needed to reach it on main; your reading is right.

   Already in flight upstream: the electrum-client half exists as bitcoindevkit/rust-electrum-client#220 (open since 2026-07-02, same rustls?/ring diff, tACK'd, awaiting maintainer review), and electrum-client#183 already prefers ring internally when both features are on — so no second electrum-client PR is needed, and the ldk-node-side exposure reduces to the VSS ordering plus the explicit ring feature in ldk-node's own manifest.

   On tls-ring/tls-aws-lc-rs features vs. a single pinned provider: that's @tnull's and @TheBlueMatt's call (they already leaned toward downstream-selectable features on #600), and we don't need the toggle either way. What we need is narrower: (a) the install — or an explicit-provider ClientConfig — runs before any TLS client is constructed, VssStore::new included; (b) a provider already installed by the host process keeps winning, as the current is_none() check does. Two data points, not asks: we consume ldk-node through orange-sdk, so an ldk-node feature only reaches us if orange-sdk re-exports it — the app-level install_default() is what we rely on regardless; and with #220 landed, ring is what everything else in our tree (spark-sdk, cdk, reqwest 0.12, and bitreq ≥0.3.5 itself) already selects, so a single pinned ring would be the zero-config outcome for us and would drop aws-lc-sys from our mobile build.

   Offer stands: our harness (Galaxy A12 + wallet-cli against our staging VSS over https://) is scripted; point us at a branch with the hoist and we'll post before/after on the current tree. No urgency from our side — we install at app init, so we route around the ordering today.