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

从 crates/spidermonkey-embedding-splicer/src/stub_wasi.rs 中的 stub_preview1 开始，并查看 commit 499a888 中的 StarlingMonkey 更新。重现 RSA importKey 的情况，然后比较对 preview1 random_get 进行 stubbing 和不进行 stubbing 时的行为。在 native 加密路径不触发 random_get trap 并验证预期行为后，即表示完成。

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.