Raised by the codex review lane on #238. Filed rather than fixed there because the launcher is
now hashed into codev/research/146-phase10-live-evidence.json, so changing it invalidates two
recorded one-hour runs and the 24-hour gate — an hour of re-running plus a restarted day-long
clock, for a robustness fix with no failing case behind it.
Two problems
1. LABEL is interpolated into deletion paths without validation.
tools/t3-server/full-protocol-run.sh takes $5 as a label and builds from it:
export T3_HARNESS_DIR="$ROOT/tools/t3-server/.runtime-$LABEL"
rm -rf "${RUNS:?}/work-$LABEL"A label containing ../ escapes the intended directory. There is no untrusted input here — it is
a developer harness invoked by hand — so this is hardening rather than a live vulnerability, but
a rm -rf built from an unvalidated argument should be validated on principle. Same for PORT
and GATE, which are used unquoted in numeric contexts.
Suggested: refuse anything but [A-Za-z0-9._-]+ for the label, and integers in range for the
port and gate.
2. Cleanup runs only on the normal path.
The script stops its server after the runner returns. An interrupted launcher — Ctrl-C, a killed
parent, a pkill — leaves the server running, and because stop can only stop a server its own
T3_HARNESS_DIR describes, a subsequently deleted runtime directory orphans it beyond any
stop, so it can only be killed by pid.
This is not hypothetical: it happened twice during #238. Once it held port 3804 and the next run
reported NO_TOKEN while ready truthfully answered about the stranger occupying the port. The
PORT_IN_USE guard added in #238 detects the symptom; a trap ... EXIT INT TERM would prevent
the cause.
Not urgent
The harness is developer-run, the blast radius is the developer's own repo, and #238 added the
port guard that catches the second problem's usual symptom. It should be fixed the next time
these runs are regenerated for another reason, so the re-run cost is already being paid.
Refs #235, #238
Raised by the
codexreview lane on #238. Filed rather than fixed there because the launcher isnow hashed into
codev/research/146-phase10-live-evidence.json, so changing it invalidates tworecorded one-hour runs and the 24-hour gate — an hour of re-running plus a restarted day-long
clock, for a robustness fix with no failing case behind it.
Two problems
1.
LABELis interpolated into deletion paths without validation.tools/t3-server/full-protocol-run.shtakes$5as a label and builds from it:A label containing
../escapes the intended directory. There is no untrusted input here — it isa developer harness invoked by hand — so this is hardening rather than a live vulnerability, but
a
rm -rfbuilt from an unvalidated argument should be validated on principle. Same forPORTand
GATE, which are used unquoted in numeric contexts.Suggested: refuse anything but
[A-Za-z0-9._-]+for the label, and integers in range for theport and gate.
2. Cleanup runs only on the normal path.
The script stops its server after the runner returns. An interrupted launcher — Ctrl-C, a killed
parent, a
pkill— leaves the server running, and becausestopcan only stop a server its ownT3_HARNESS_DIRdescribes, a subsequently deleted runtime directory orphans it beyond anystop, so it can only be killed by pid.This is not hypothetical: it happened twice during #238. Once it held port 3804 and the next run
reported
NO_TOKENwhilereadytruthfully answered about the stranger occupying the port. ThePORT_IN_USEguard added in #238 detects the symptom; atrap ... EXIT INT TERMwould preventthe cause.
Not urgent
The harness is developer-run, the blast radius is the developer's own repo, and #238 added the
port guard that catches the second problem's usual symptom. It should be fixed the next time
these runs are regenerated for another reason, so the re-run cost is already being paid.
Refs #235, #238