v0.1.2 — hardened Docker playground

Sprout v0.1.2 makes the frozen language safe to host as an online playground that runs strangers' code — and ships the container to do it.

Sandbox hardening

• use <module> is now blocked in sandbox mode. It loads and runs another file from disk, and being a statement (not a builtin) it slipped past the block list — untrusted code could have reached the filesystem through it. Now refused like read/write/system/get. Normal module loading outside the sandbox is unchanged.
• The sandbox self-test probe now covers 11 dangerous ops, run under SPROUT_SANDBOX=1 on every CI job.

A hardened Docker playground (playground/)

• Dockerfile — multi-stage (gcc build → debian-slim runtime; no compiler, no curl), runs as non-root uid 10001, with SPROUT_SANDBOX=1 baked into the image so the block holds even if the entrypoint is bypassed.
• run.sh — runs one untrusted submission, sandboxed and resource-limited (wall-clock + CPU timeout, output cap, vmem/file/proc ulimits).
• README.md — the full hardened docker run (network none, read-only rootfs, tmpfs, --cap-drop ALL, no-new-privileges, pids/mem/cpu caps), each layer explained, plus how to wire it into a backend. States plainly: the flag is necessary but not sufficient — the host still caps CPU/mem at the OS level.
• A CI playground job builds the image and asserts safe code runs while file/shell/network are blocked.

Verified

An adversarial security review (3 lenses — container escape, runner robustness, sandbox completeness; 23 candidate findings) confirmed zero real issues for the actual threat model (untrusted code on stdin): every proposed "escape" required controlling the docker run command line, which the host owns. The review independently re-verified the sandbox, including the use fix.

All CI green: build & test on Linux/macOS/Windows, AddressSanitizer + GC-stress, and the new Docker playground image.

Windows installer: SproutSetup.exe below.