Team/silverex. goboxd PR Stage 1

[googleboy-byte]

Team

silverex - solo

Members

Member 1: Mainak Dasgupta

Framework

chi: lightweight router with no magic, clean middleware chaining, and a handler signature that composes directly with the semaphore-based concurrency layer without boilerplate.

Running locally

Clone the repo and ensure Docker is running. make run builds the image and starts the container. make test runs unit tests, make integration runs end-to-end tests against all 8 languages, make corpus runs the full adversarial test suite (50 cases), make secure verifies security mitigations, and make load benchmarks at c=1/10/50/100. The container requires --privileged --cgroupns=host for nsjail and cgroup v2 memory tracking, both are set in the Makefile and docker-compose.yml.

Languages supported

py3, cpp, c, bash, js, rust, java, verilog

Bonus languages registered and passing /readyz smoke probes: rust, go, kotlin, csharp, ruby, lua, ocaml, swift, zig

Security holes closed (7/7)

1. Path traversal: internal/validate/validate.go:17: ValidateFilename rejects path separators, .., leading dots, and absolute paths on all client-supplied filenames before any filesystem operation
2. Shell-style directory commands: internal/runner/runner.go:125: all process execution uses exec.CommandContext with direct argv arrays; directory management uses os.MkdirTemp and os.RemoveAll, no sh -c anywhere in the codebase
3. Compiler flag injection: internal/validate/validate.go:38: per-language flag_allowlist in languages.yaml, validated via filepath.Match glob matching; disallowed flags return 400 disallowed_flag
4. Request size limits: internal/handler/run.go:96: 512KiB HTTP body via MaxBytesReader, 256KiB source via ValidateRunRequest, 64KiB per-test stdin and expected via ValidateTest, 64KiB captured output via io.LimitReader with [TRUNCATED] marker
5. UID collisions: internal/runner/runner.go:52: os.MkdirTemp guarantees unique per-request working directories; no counter, no retry, no reuse
6. Unbounded child output:internal/runner/runner.go:216: stdout and stderr each capped at 64KiB via io.LimitReader; remainder drained to io.Discard to prevent pipe deadlock on chatty programs
7. Stale jail directories: cmd/goboxd/main.go:36: startup sweep removes orphaned directories older than 10 minutes; all per-request cleanup via defer os.RemoveAll scoped to the run goroutine

Bonus: memory tracking

memory_peak_kb is populated via cgroup v2 polling. The runner starts a goroutine before cmd.Start() that polls /sys/fs/cgroup/NSJAIL.*/memory.peak every 10ms during execution. Requires --cgroupns=host so the container sees the host cgroup hierarchy. OOM conditions (bad_alloc, MemoryError) are mapped to memory_exceeded. Documented in docs/cgroups_mem_tracking.md.

Benchmarks

docs/benchmarks.md

[thesouldev]

Evaluation Summary

Team: pr4-silverex · Rank: 5 / 45 · Weighted score: 71.6 / 100

Area (weight)	Score	What it covers
Technical (~60%)	77.6%	API contract, security holes, concurrency + benchmarks, plug-and-play languages
Code quality / SDLC (~30%)	60.7%	tests, clean git history, lint, docs
Communication (~10%)	66.7%	README clarity, framework justification

Checks:

• Build: Yes
• Health: Yes
• CI: no-actions
• Sandbox: nsjail
• Happy-path: 9/9

Notes: framework go-chi/chi (verify justification in README)

Thanks for participating! Scores reflect evaluation against the spec. Reply here if you have questions.

[googleboy-byte]

Evaluation Summary

Team: pr4-silverex · Rank: 5 / 45 · Weighted score: 71.6 / 100

Area (weight) Score What it covers
Technical (~60%) 77.6% API contract, security holes, concurrency + benchmarks, plug-and-play languages
Code quality / SDLC (~30%) 60.7% tests, clean git history, lint, docs
Communication (~10%) 66.7% README clarity, framework justification
Checks:

• Build: Yes
• Health: Yes
• CI: no-actions
• Sandbox: nsjail
• Happy-path: 9/9

Notes: framework go-chi/chi (verify justification in README)

Thanks for participating! Scores reflect evaluation against the spec. Reply here if you have questions.

Are commits and improvements allowed before the in-person combined Stage 2/3 at Paradox, or is the current submission considered frozen until then?

Also, will there be more detailed feedback shared regarding the technical/code quality/communication scoring breakdown, especially around SDLC practices or architectural decisions that affected evaluation?

One more question: if we continue contributing in the open-source phase, are architecture-level improvements beyond the explicit spec (for example around security hardening, load distribution, edge-case handling, or operational behavior) viewed positively from a scoring/review perspective, or would staying strictly within the spec be preferred?

Thanks again for organizing this. This has been a great learning opportunity.