feat(plugins): give the sandbox a CSPRNG

[lovepixel-git]

Fixes #387.

Verified before touching anything

Probed a live VM on main:

{"getRandomValues":"undefined","randomUUID":"undefined","subtleDigest":"function","hostRandomBytes":"undefined"}

After:

{"getRandomValues":"function","randomUUID":"function","subtleDigest":"function","hostRandomBytes":"function"}

So Math.random and Date really were the only entropy in the sandbox, which is why the reporter had to mint MCP access tokens in the browser and POST them to the server — a capability the server owns depending on a client for its entropy.

The constraint that shapes the fix

crypto.getRandomValues is synchronous by spec. Every existing crypto path goes through __hostCall, which vm.ts documents as returning a VM-side Promise:

Wire __hostCall as a SYNCHRONOUS VM function. The host returns a VM-side Promise immediately and resolves it later from JS-land.

A shim built on that bridge would hand back a Promise, so crypto.getRandomValues(new Uint8Array(8)) could not work without an await no real caller writes. So this adds a dedicated synchronous host function, __hostRandomBytes, next to __hostSleep and __log, returning base64 that the shim decodes with the codec already shared by fetch and the digest path.

Left ungated, matching the reasoning the crypto handlers already document: pure computation, no I/O, nothing to escalate. Same model as Math and JSON.

Spec conformance where it was free

• Integer-typed views only. Float32Array, Float64Array, plain arrays and undefined all throw TypeMismatchError.
• The WebCrypto 65536 byte per-call quota, QuotaExceededError above it. Enforced in the shim and independently in the host function, so a plugin that reaches __hostRandomBytes directly still cannot ask the host for an unbounded allocation. One exported constant backs both, so they cannot drift.
• Fills through a byte view, so element width and byteOffset are honoured. There is a test asserting a Uint8Array(buffer, 4, 8) view leaves the surrounding bytes untouched.
• randomUUID sets the RFC 9562 version and variant bits.
• QuickJS has no DOMException, so the spec's error name rides on a plain Error. Plugins branching on err.name behave the same.

The shim augments globalThis.crypto rather than replacing it, so it is order-independent against the subtle shim and only has to follow the base64 codec. One test asserts crypto.subtle's three methods still exist afterwards.

Tests

src/__tests__/server/pluginSandboxCsprng.test.ts, 12 cases in a real VM through the existing createPluginVm recorder harness. Beyond presence they cover: synchronous return of the same array instance (a Promise there would mean it went through __hostCall), varied non-zero bytes (an all-zero fill is the signature of a bridge that silently no-ops), different bytes across successive calls, wide element types, byteOffset isolation, zero-length arrays, both quota boundaries, every TypeMismatchError case, and 200 UUIDs with no collision.

• bunx tsc -b exit 0
• bun run lint clean
• bun run build clean
• bun test 6628 pass, 0 fail

One note in case it saves you time: the bundle-size budget test fails against a stale dist/. Rebuild before running the full suite and it is green. I chased that one down and it is not related to this change.

Deliberately not in scope

The reporter also mentions crypto.subtle being HMAC-only, so plugins cannot sign an RS256 JWT. That is a separate surface and a bigger call, and they offered to file it separately. getRandomValues alone unblocks everything else they listed.