fix(sdk): enable rustls' ring provider — APK died at 'Failed to start / Could not determine the process-level CryptoProvider' #15
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "wt/t_dcb8565a"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Symptom
The APK built, installed and opened. Pressing Open on the unlock screen failed at runtime:
Not a Tor problem, not an Arti publishing problem — a missing rustls provider.
Root cause (confirmed against the real feature graph, not inferred)
rustls0.23 selects itsCryptoProviderfrom its ownring/aws-lc-rscrate features, never from which crypto crates happen to be linked. Arti reaches rustls throughtor-rtcompatwithdefault-features = false, and nothing in theonionwire-sdkworkspace turned a provider feature on:No
ring, noaws-lc-rs→ rustls compiled with zero providers → the first TLS config built from the process default panics with the message above (rustls-0.23.44/src/crypto/mod.rs:249).ringdid appear incargo tree— pulled in bysnowfor Noise IK. That was never relevant to rustls; it is a different consumer of the same crate.aws-lc-rsis absent from the lock entirely, so there was no second-provider conflict to report.aws-lc-rswould also be the wrong choice for this target: it wants CMake and a C toolchain for the NDK and fights the cross-compile.Fix (5 files, all under
crates/onionwire-sdk/)Cargo.toml— explicit provider pin:Committed in
411194awithout the feature first, so the regression test fails against the pre-fix graph.src/lib.rs— belt and braces:install_crypto_provider(), aOnceLock-guardedrustls::crypto::ring::default_provider().install_default()with the already-installedErrignored. Called fromopen_wire()beforeNode::start_with_passphrase, so the cdylib is correct regardless of how a consumer's feature graph resolves rustls. Not exported over UniFFI — Rust-side plumbing only.Two regression tests, in separate test binaries on purpose (a provider installed in one would mask the other):
tests/provider_resolution.rs— the invariant Arti relies on: the process default must resolve with nobody callinginstall_default().tests/init_provider.rs—install_crypto_provider()installs the default; the second call is a no-op;ClientConfig::builder()then works.The Linux TUI is untouched: root
Cargo.tomlfeatures are unchanged,default = ["native-tls"]still holds, and the two Cargo workspaces stay separate. No protocol, TUI,store.rs,session.rs, schema or invite-format changes.Verification
RED — host, pre-fix (
411194a), reproduces the device error verbatim:GREEN — host, post-fix:
Root-crate gates (unchanged working tree, lock untouched):
On-device: actually run, not inferred. No phone was attached, so this ran on a Pixel 7 AVD (API 35, x86_64,
-gpu swiftshader_indirect), which exercises the sameopen_wirepath. A/B with the same emulator, same passphrase input, same tap coordinates:411194a)Failed to start+ exactly theCould not determine the process-level CryptoProvidermessagePublishing onion service…→ roster screenPost-fix, the node reached Ready on the emulator: Arti bootstrapped, the v3 onion service published, the roster showed
adb logcat -d | grep -c CryptoProviderover the whole session: 0.Artifact-level check that the fix is really in the packaged library, not just the host test binary (mangled
rustls::crypto::ringsymbols in the shipped.so):Build
android/app/build/outputs/apk/debug/app-debug.apk— 62,621,963 bytes (arm64-v8a + x86_64)android/sdk/build/outputs/aar/sdk-release.aar— 14,671,935 bytesFor a phone, arm64 is all that is needed: omit the ABI property to get the default single-ABI build (~38 MB).
Base
Cut from
389d8f1= currentorigin/main.git rev-list --left-right --count origin/main...HEAD→0 2. Audit items F1–F7 from PRs #3/#7/#12/#13/#14 are present in the base and untouched by this diff (which only adds/or edits the 5 files listed above).RED. The APK builds, installs and opens, but the first rustls config built from the process default panics one call deep inside Arti's rustls backend: Could not automatically determine the process-level CryptoProvider from Rustls crate features. Call CryptoProvider::install_default() before this point ... rustls 0.23 picks its provider from its own 'ring' / 'aws-lc-rs' crate features, not from which crypto crates happen to be linked. Arti reaches rustls via tor-rtcompat with default-features = false, so neither provider feature is on and rustls compiles with zero providers. 'ring' does appear in cargo tree, pulled in by snow for Noise -- unrelated and irrelevant. This commit adds rustls as an explicit dependency with no provider feature (no behaviour change: it is already in the graph that way) so the test can name the type, plus the regression test. On the host it reproduces the device's panic verbatim. The SDK lockfile is resynced with the root Cargo.toml on main (onionwire 0.2.1, rpassword, md-5, rtoolbox) in the same commit so the test build is against a consistent lock.GREEN. rustls 0.23 selects its CryptoProvider from its own 'ring' / 'aws-lc-rs' crate features. Arti reaches rustls through tor-rtcompat with default-features = false and nothing in this workspace turned a provider feature on, so rustls was compiled with zero providers and the first TLS config built from the process default panicked: Could not automatically determine the process-level CryptoProvider from Rustls crate features. ... That is the 'Failed to start' screen on the unlock path. The 'ring' crate being present in the graph (via snow, for Noise) never had anything to do with it. 'ring', not 'aws-lc-rs': aws-lc-rs wants CMake and a C toolchain for the NDK and fights the cross-compile. Belt and braces: open_wire() now calls install_crypto_provider() before Node::start_with_passphrase, a OnceLock-guarded ring::default_provider().install_default() with the already-installed Err ignored. That keeps the cdylib correct regardless of how a consumer's feature graph resolves rustls. aws-lc-rs is absent from the lock, so there is no two-provider conflict to report. Evidence: cargo test --release --test provider_resolution before: panicked at rustls-0.23.44/src/crypto/mod.rs:249 (device message) after: 1 passed cargo tree -f '{p} [{f}]' -p rustls rustls v0.23.44 [log,logging,ring,std,tls12]