open-standards/sandbox/sandbox-rs/crates/sandbox-exec-wasm
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 7a847b18b0
Some checks failed
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (push) Has been cancelled
sandbox: JavaScript inside the S2 wasm sandbox
run_js runs a script in the sandbox's own wasm executor, inside a
pure-Rust JavaScript engine compiled to wasm (guests/js), so a script
has exactly the S2 surface: fuel for its instructions, a memory cap,
and only the brokered host calls its grant allows. The script goes in
and its value or what it threw comes out through the journaled
key-value store, so a run replays; Date reads the sandbox clock and
Math.random its seeded draw, each only where granted, and the zone is
UTC. A script that never ends is ended by its fuel, recorded as a
CPU-time breach. run_js refuses a grant that does not let the script in
or the result out, each direction checked alone.

The engine is a module of record (3.1 MB), held to its SHA-256 and
checked before loading. Its toolchain leaves imports it never calls
(a time crate's host glue); WasmExecutor::run_with links unbrokered
imports as traps for it alone, granting nothing. run_with also seeds
the run's key-value store and returns it. Rebuilt on aarch64 Linux from
the same sources and toolchain the module differs (measured, recorded
in the MANIFEST), so the record is what runs. SPEC §5.9.

Falsified, each turns a test red: any module accepted, the read or the
write left unchecked (the first survived until the test checked each
direction alone), and the unbrokered imports left unlinked.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-12 04:36:23 -05:00
..
src sandbox: JavaScript inside the S2 wasm sandbox 2026-11-12 04:36:23 -05:00
Cargo.toml sandbox: JavaScript inside the S2 wasm sandbox 2026-11-12 04:36:23 -05:00