The JavaScript interpreter binary is built from second-state/wasmedge-quickjs (pinned to the abandoned v0.6.1-alpha, T364564), a low-activity side-project wrapping Bellard's QuickJS. The wider community has moved to QuickJS-NG, which receives regular releases. We should migrate our build source to a maintained QuickJS-NG WASI build (e.g. vercel-labs/quickjs-wasi), or QuickJS-NG built from source ourselves, so that the JS engine keeps receiving security and language-feature updates.

Technical notes

This is a build-source change, not a run-time change. We already run the QuickJS .wasm as a generic wasm32-wasip1 module under wasmtime and inject all sandbox controls ourselves in Rust — fuel/memory caps, a single read-only preopen, no host-env inheritance, in-process stdio channels, single-use executors (ADR-0001). The wasmedge runtime is not involved. The only coupling to second-state/wasmedge-quickjs is executors/wasm-utilities/build-quickjs-for-wasmtime, which clones, cargo builds to wasm32-wasip1, and hand-patches the resulting .wat (interpreters/quickjs.diff, a sock_accept arity fix).

Expected work:

• (1) replace the build recipe to source QuickJS-NG;
• (2) adapt the JS glue if the builtin module surface changed — QuickJS-NG renamed the modules to the qjs: prefix, so import * as std from 'std' in main.js and the getline/print/flush calls in utils.js need re-checking;
• (3) the quickjs.diff patch likely becomes unnecessary against a current wasi-sdk build and should be dropped deliberately;
• (4) re-run the security evaluation for the new engine against the ADR-0001 constraints (__code__ replacement, Symbol.species, frozen-globalThis delete), plus a fuzz pass; and
• (5) opportunistically check whether the newer engine affects the known issues with concurrent-wave resulting in Z507 failures (suspected host/wasmtime interaction rather than engine bug).

Sizing note: building QuickJS-NG from source ourselves (wasi-sdk + CMake) is roughly equivalent in effort to the existing RustPython build stack and yet avoids the rustup-on-Debian std-grafting pain that build carries (T430145); adopting vercel-labs/quickjs-wasi is lighter still. Recommend a short spike first to confirm the module-surface delta and whether the .wat patch drops out, before committing to the full migration. We are explicitly not vendoring second-state/wasmedge-quickjs as an interim step. Worth recording the outcome as an ADR (following ADR-0002 for RustPython).

Acceptance criteria

• The JavaScript interpreter .wasm is built from a maintained QuickJS-NG source, with no remaining dependency on second-state/wasmedge-quickjs, and the full test suite (test-rust, test-js-direct) passes.
• The security evaluation is re-run against the new engine and the result is documented (ADR + any ADR-0001 updates).