[guybedford]

This enables SystemRandom on wasm32-unknown-emscripten.

getrandom 0.4 implements Emscripten via libc getentropy, which Emscripten's runtime backs with crypto.getRandomValues, so this is the environment's CSPRNG rather than a custom or rdrand implementation, matching the criterion for the existing target_os list.

• Adds target_os = "emscripten" to the SystemRandom cfg in src/rand.rs.

No build.rs changes were needed; the existing wasm32 C build works as-is with CC=emcc AR=emar.

Tested locally with Emscripten 6.0.10 and Node 22: cargo test --target wasm32-unknown-emscripten with CARGO_TARGET_WASM32_UNKNOWN_EMSCRIPTEN_RUNNER=node passes the full suite including rand_tests and doctests.

[JustYannicc]

This is the same SystemRandom cfg omission we encountered with released Ring 0.17.14. A downstream focused probe reproduced the pristine compile failure, then passed compilation, linking and execution with only Emscripten added to this cfg.

Additional coverage was Emscripten 4.0.10, Rust nightly-2026-03-01, Node 24.18.0 with JSPI, getrandom 0.2.17 and Rustls 0.23.45. It used the existing getrandom → libc getentropy → Emscripten random_get route. This is older-release evidence; your PR uses current Ring/getrandom 0.4 and already reports the newer SDK/full suite.

The focused Rust calls are:

use ring::rand::{SecureRandom, SystemRandom};

let mut bytes = [0u8; 32];
SystemRandom::new().fill(&mut bytes).unwrap();
let provider = rustls::crypto::ring::default_provider();
provider.secure_random.fill(&mut bytes).unwrap();

Our synthetic host also checks entropy failure propagation. It proves the exercised RNG route, not a TLS handshake or a complete application. No duplicate PR is needed for this fix.