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 した場合としない場合の動作を比較します。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.