tamperward 2.16.0 → 2.16.3

package/README.md

@@ -144,6 +144,18 @@ Before starting the agent, the envelope
 3. records the installed `node_modules` content fingerprint, where one exists; and
 4. refuses an already-dirty tree unless the operator explicitly accepts the risk.
 
+**2.16.3 deliberately disables the 2.16.2 run→verify dependency-attestation reuse.**
+The envelope still takes a complete dependency checkpoint immediately before `runVerify`,
+and the nested verifier independently takes its own entry checkpoint. A clean local run
+therefore performs **6 complete dependency snapshots and 0 reused snapshots** on every
+platform and lifecycle outcome. The optimization is not re-enabled merely because Linux
+established descendant ownership: an independent verifier-entry read is a clearer trust
+boundary than coupling dependency integrity to same-UID lifecycle supervision. The checks
+after visible execution, after pristine execution, and at the envelope's final quiescence
+boundary remain independent full reads as well. Set `TAMPERWARD_DIAGNOSTICS=1` to report
+`full_snapshots`, `reused_snapshots`, aggregate snapshot wall time, lifecycle ownership,
+and `entry_reuse=no`.
+
 The hooks then steer the agent while it works: they read live state, deny known
 weakening operations, detect protected-tree drift, and sweep the turn's net
 changes. The `Stop` hook runs that sweep — it does **not** invoke `verify`.
@@ -184,15 +196,35 @@ After the runtime exits its exit code is treated as untrusted, and the envelope
 checks that post-agent `HEAD` still descends from the entry commit; the committed
 changes over `entry...HEAD`; staged, unstaged and untracked non-ignored worktree
 changes; dependency drift and whether the tree stayed quiescent; and the
-verification outcome. For agent runtimes that may hang, `--agent-budget <seconds>`
-adds an operator-owned wall-clock boundary around the **agent itself** (separate from
-the verifier's `--budget`). On expiry TamperWard terminates the owned process tree,
-then still performs the same post-timeout adjudication. A clean timeout is
-`AGENT_TIMEOUT` / exit 124; any enforcement failure or cannot-adjudicate result
-still outranks that runtime status. On POSIX the agent starts in its own process
-group; on Linux the timeout also enumerates the agent's `/proc` descendant tree so
-a child that escaped the group with `setsid()` is terminated before adjudication.
-Windows uses `taskkill /T /F` as the explicit process-tree fallback.
+verification outcome. Since **2.16.3**, every wrapped agent goes through a lifecycle
+supervisor even when no runtime budget is requested. Ordinary POSIX descendants remain in
+an owned process group. On Linux the stronger boundary uses a fixed, non-caller-writable
+system `python3` launched with isolated startup (`-I -S -E`), supervisor cwd `/`, and a
+minimal supervisor environment; the agent receives its separately frozen original cwd and
+environment. The supervisor sets `PR_SET_CHILD_SUBREAPER`, so orphaned descendants from
+double-fork/`setsid()` are reparented to it by the kernel. Before adjudication begins it
+kills the agent process group plus adopted children and does not report lifecycle ownership
+until `waitpid(-1, WNOHANG)` reaches the kernel **ECHILD** condition. An unreadable child
+list, failed kill, abnormal supervisor exit, unavailable trusted interpreter, or drain
+deadline fails closed before adjudication. The same-UID result file is evidence only after
+normal supervisor completion, so forging it and killing the supervisor cannot manufacture a
+trusted lifecycle result.
+
+Linux therefore requires Python 3 with the standard `ctypes`/process modules available at
+a fixed trusted system path; TamperWard does not resolve this supervisor through candidate
+`PATH`, `PYTHONPATH`, user site-packages, or candidate cwd. **Linux `tamperward run`
+also refuses to start when the caller's uid or effective uid is 0/root.** Root can write
+ordinary system interpreter paths, so the same-UID trust argument used by this lifecycle
+backend is not meaningful there. `tamperward doctor` reports this explicitly as a
+BROKEN platform posture rather than misdiagnosing it as a missing Python installation.
+`--agent-budget <seconds>`
+adds an operator-owned wall-clock boundary around the same lifecycle (separate from the
+verifier's `--budget`). A clean timeout is `AGENT_TIMEOUT` / exit 124; enforcement or
+cannot-adjudicate still outranks it. Windows retains `taskkill /T /F`; other non-Linux
+platforms retain process-group/fingerprint/quiescence safeguards but do not claim the Linux
+subreaper boundary. A detached process that escapes those weaker platform controls remains
+an explicit residual tracked in **#379**, not part of the Linux guarantee.
+Dependency-attestation reuse remains disabled on all platforms.
 
 `tamperward verify` materialises two temporary copies — they are **not
 sandboxes**, and both execute agent-controlled code. The visible copy runs the
@@ -325,8 +357,14 @@ Public rulesets can be read anonymously; set `GH_TOKEN` or `GITHUB_TOKEN` when
 authentication is required.
 
 A real deployment needs a verify command configured — the generated CI verify step
-**fails closed (exit 2) without one** rather than passing quietly. In
-`.tamperward.yml`:
+**fails closed (exit 2) without one** rather than passing quietly. Since 2.16.1,
+`tamperward init` ends with a separate **VERIFICATION SETUP** status: it says either
+`verification configured — <command>` or prominently reports
+`INCOMPLETE: verification not configured — CI will fail closed`. It can suggest a
+single high-confidence command such as `npm test`, `pytest`, `tox`, `cargo test`
+or `go test ./...`; multiple candidates are listed without choosing one. Suggestions
+are advisory only — init never writes an inferred verifier command because that command
+is part of the trust anchor. In `.tamperward.yml`:
 
 ```yaml
 verify: