Semi-automated Judging Assistant
James Bowery
This repository minimizes the manual work required to evaluate a Hutter Prize submission. judging_assistance.sh rebuilds and runs the submitted software, enforces the technical resource limits, verifies the result, and records the evidence and proposed score for human review.
Entrant-provided processes run within Docker containers to minimize the risk of an adversarial entry. The security model is conditioned on a Linux host whose kernel is hardened against container escape.
The authoritative rules remain the Hutter Prize detailed rules. Entrants should follow ENTRANT_INSTRUCTIONS.md.
From the repository root:
The work filesystem must have at least the configured 100 GB allowance. By default, submitted-archive qualification and rebuilt compression may overlap (--jobs 2). Use --serial when a disputed CPU timing must be repeated without concurrent work. --geekbench-score N reuses a separately verified Geekbench 5 single-core score.
The current Docker worker executes Linux x86/x86-64 entries. The manifest also defines Windows x86/x86-64 names so the same orchestration contract can be used by a native Windows worker; this Linux worker rejects a Windows manifest rather than running it under an unscored compatibility layer.
Invoke judging_assistance.sh as an ordinary user. When necessary, it installs Git LFS through the separate install-host-dependencies.sh helper, materializes the required repository objects, and re-executes the trusted host orchestrator through sudo to access Docker. The customary password prompt is the only required interaction. Results created by the elevated process are returned to the invoking user's ownership.
The Docker socket must not be made world-writable; access to it is root-equivalent. Contestant executables do not receive that access and run as UID 65532 in their execution containers.
Before any entrant-provided code is unpacked, built, or executed, the orchestrator runs a host-security preflight. It rejects a non-Linux daemon, a nonlocal Docker endpoint, a daemon using a kernel other than the host kernel, inactive seccomp filtering, failure to apply no-new-privileges, or the absence of a verifiably enforcing AppArmor or SELinux container profile. The checks follow Docker's documented capability and kernel-isolation model and verify the resulting test container rather than relying only on daemon configuration.
The preflight records whether rootless Docker or user-namespace remapping maps container UID 0 away from host UID 0. Their absence currently produces a warning: entrant executables still run as UID 65532, but that is not a separate user-namespace boundary. The preflight also warns that local inspection cannot prove the absence of an unpatched host-kernel or Docker Engine vulnerability. Its complete findings are retained as host-security.env in the results tree.