Team/greyapple

[christiano-developer]

goboxd

Team Members

• Christiano Fernandes

HTTP Framework Choice

We chose the Go standard library's net/http framework (specifically using the improved routing capabilities of ServeMux from Go 1.22) because it delivers raw, zero-dependency HTTP performance with minimal memory overhead.

How to Run Locally

The project is configured to run fully isolated inside Docker. Spin up the Go daemon container by running make run, which automatically builds and exposes the HTTP service on port 8080. Run unit tests with make test, integration/sandbox tests with make integration, code quality checks with make lint, and performance runs with make load (refer to the project Makefile for target commands).

---

System Architecture & Route Lifecycles

goboxd consists of three primary HTTP routes configured via a centralized configuration registry, validator layer, and concurrency pool scheduler:

graph TD
    Client[HTTP Client] --> Mux[net/http ServeMux]
    Mux -->|POST /run| RunH[RunHandler]
    Mux -->|GET /readyz| ReadyH[ReadyHandler]
    Mux -->|GET /info| InfoH[InfoHandler]

    RunH --> Val[validate package]
    RunH --> Reg[languages Registry]
    RunH --> Pool[worker.ConcurrencyPool]
    RunH --> Exec[executor package]
    Exec --> Sand[sandbox package]
    Sand --> NsJail[nsjail Binary]

    ReadyH --> Reg
    ReadyH --> ExecLook[exec.LookPath Check]

    InfoH --> Reg
    InfoH --> ReadyH
    InfoH --> Pool
    InfoH --> Stats[atomic Request Counter]

Loading

Route Lifecycles

• POST /run (Execution Pipeline): Rejects payload sizing overflows (> 4 MiB), validates filename security and flag allow-lists, clamps limits based on load-adaptive window trackers, enqueues the request in the priority pool scheduler, creates an ephemeral /tmp workspace, and executes/evaluates compilation and execution runs inside isolated nsjail containers sequentially.
• GET /readyz (Liveness & Probe Check): Runs a startup assertion suite, checking if the nsjail binary is present and executing dynamic smoke check command overrides (e.g., runtime --version probes) to verify toolchain responsiveness.
• GET /info (Server diagnostic telemetry): Exposes current active limits, loaded registry configurations, and live metrics (in-flight count, queue saturation levels, total runs, internal failure counts, and free disk space in the sandbox workspace).

---

Concurrency & Scheduling Architecture Highlights

goboxd uses a custom-built concurrency engine to manage heavy execution workloads under extreme spikes without crashing the host.

1. Shortest Job First (SJF) Min-Heap with Starvation Aging

To avoid head-of-line blocking from slow compiles/runs, pending requests are scheduled via a Min-Heap Priority Queue ordered by estimated execution cost:

Cost = WallTime(s) × (1.0 + MemoryKB / 1048576.0) × TestCount

To prevent heavy requests from starving indefinitely, we implement starvation prevention by dynamically subtracting an aging factor from the item's priority score:

Priority Score = Cost - 2.0 × WaitTime(seconds)

The scheduler always pops the item with the lowest Priority Score first, ensuring all jobs modify priority and execute over time.

2. Load-Adaptive Resource Clamping

To survive massive traffic spikes, the server monitors incoming request rates over a sliding 10-second window. Once request rate R > 5 req/sec, the validator dynamically clamps the upper limits allowed for request overrides:

Max Wall Time = max(1s,  15s - 0.5 × (R - 5))
Max Memory    = max(min_boot_mem,  2GB - 50MB × (R - 5))

Clamped adjustments are returned to the client in a warnings field.

3. Dynamic Retry-After Estimation

When concurrency reaches capacity (8 workers active + 500 queued), the server rejects new requests with a 503 Service Unavailable. Instead of a static guess, we estimate the queue clearing duration based on the moving average execution time (T_avg) of the last 100 successful runs, returning it in the HTTP headers:

Estimated Wait = (QueueSize × T_avg) / MaxConcurrency

---

Security Fixes (7/7 Closed)

We resolved all seven security vulnerabilities with the following host and sandboxing boundaries:

1. Path Traversal via Filename: Checked in [validate.go:L23](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/validate/validate.go#L23) by blocking requests with path separators (/, \) or dot prefixes (., ..).
2. Shell-Style Directory Commands: Resolved in [executor.go:L40](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/executor/executor.go#L40) by using Go's safe os filesystem APIs (os.MkdirTemp, os.RemoveAll, os.WriteFile) instead of string-formatted shell commands.
3. Compiler-Flag Injection: Closed in [validate.go:L66](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/validate/validate.go#L66) by verifying all build flags against the allowed YAML specifications (rejecting compile-time exploits with HTTP 400).
4. No Request Size Limits: Closed at the HTTP layer in [handler.go:L35](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/handler/handler.go#L35) by capping body reads to 4 MiB, and at the field validation level in [validate.go:L46](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/validate/validate.go#L46), [validate.go:L56](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/validate/validate.go#L56), and [validate.go:L193](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/validate/validate.go#L193) by capping source size to 256 KB, tests to 50, and inputs to 64 KB.
5. UID Collisions Under Load: Closed in [executor.go:L31](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/executor/executor.go#L31) by implementing an atomic, process-unique UID/GID generator mapping concurrent requests to unprivileged ranges.
6. Unbounded Child Output: Closed in [executor.go:L270](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/executor/executor.go#L270) using a cappedWriter to truncate process streams at 64 KiB with a clear marker, preventing host OOM.
7. Stale Jail Directories: Closed on request exit paths using a defer cleanup in [executor.go:L45](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/executor/executor.go#L45), combined with a startup orphan garbage collection sweep in [executor.go:L295](https://github.com/christiano-developer/goboxd/blob/team/greyapple/internal/executor/executor.go#L295) clearing temporary folders older than 5 minutes.

Languages Supported

All 7 in-scope languages are dynamically registered via YAML (Python 3, C, C++, Java, Bash, JavaScript, and Verilog) with support for customizable health probes.

Concurrency Benchmarks

Detailed latency percentiles and performance graphs under load are available in the [Concurrency Benchmarks Documentation](https://github.com/christiano-developer/goboxd/blob/team/greyapple/docs/benchmarks.md).

[thesouldev]

Evaluation Summary

Team: pr40-greyapple · Rank: 4 / 45 · Weighted score: 73.7 / 100

Area (weight)	Score	What it covers
Technical (~60%)	82.8%	API contract, security holes, concurrency + benchmarks, plug-and-play languages
Code quality / SDLC (~30%)	57.1%	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

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