Possible regression in native crypto paths in componentize-js 0.20.0 due to preview1 random_get stubbing

Start with stub_preview1 in crates/spidermonkey-embedding-splicer/src/stub_wasi.rs and review the StarlingMonkey update in commit 499a888. Reproduce the RSA importKey case, then compare behavior with and without stubbing preview1 random_get. Done means the native crypto path completes without the random_get trap and the intended behavior is verified.

Hi all,

@maxim-le and I hit a runtime trap in componentize-js 0.20.0 and wanted to share what we found in case we are understanding the behavior correctly. We may be missing context, so I’m filing this as a question / possible bug rather than assuming the current implementation is wrong.

Symptom

We see traps like:

wasm trap: wasm unreachable instruction executed
0: ... !random_get

This happens for WebCrypto operations that appear to go through native crypto code, for example RSA private-key crypto.subtle.importKey("pkcs8", ...).

A simplified repro for us is:

async function main() {
  const pem = `-----BEGIN PRIVATE KEY-----
 ...
-----END PRIVATE KEY-----`;

  const pemBody = pem
    .replace(/-----BEGIN PRIVATE KEY-----/, "")
    .replace(/-----END PRIVATE KEY-----/, "")
    .replace(/[\r\n\s]/g, "");

  const keyBytes = Uint8Array.from(atob(pemBody), c => c.charCodeAt(0));

  const key = await crypto.subtle.importKey(
    "pkcs8",
    keyBytes.buffer,
    { name: "RSASSA-PKCS1-v1_5", hash: "SHA-256" },
    false,
    ["sign"]
  );

  return { imported: true, type: key.type };
}

What we found

The relevant code seems to be in:

crates/spidermonkey-embedding-splicer/src/stub_wasi.rs

fn stub_preview1(module: &mut Module) -> Result<()> {
    // random comes from prevew2 only in StarlingMonkey
    stub_import(module, PREVIEW1, "random_get", unreachable_stub)?;
    Ok(())
}

The stub predates 0.20.0 by a long time. The main notable change between 0.19.3 (The previous version we used) and 0.20.0 relevant to this area appears to be the StarlingMonkey update in 499a888 ("Update StarlingMonkey (#325)"), which is consistent with the issue only becoming observable for us in 0.20.0.

Current hypothesis

Our current guess is:

• componentize-js 0.20.0 bumped StarlingMonkey in a way that now exercises a native crypto / libc entropy path that actually reaches preview1 random_get
• once that path is exercised, the existing stub becomes visible as a trap

What we verified locally

We tested a local patch that stops stubbing random_get, rebuilt the splicer artifacts, and reran the same RSA importKey case.

With that patch in place, the trap disappeared and the operation completed successfully.

Because of that, it seems plausible that preview1 random_get still needs to remain available for some native crypto paths, even if most JS-visible randomness is coming from preview2.

Question

Does this sound like a real bug from your perspective, or is there intended behavior here that we are overlooking?

If useful, I’m happy to open a follow-up PR :)

Thanks.