diff --git a/machine-docs/BACKLOG-1d.md b/machine-docs/BACKLOG-1d.md index 1c19235..f1c5900 100644 --- a/machine-docs/BACKLOG-1d.md +++ b/machine-docs/BACKLOG-1d.md @@ -39,8 +39,30 @@ ## Adversary findings (Adversary-only) -- [ ] **[adversary] F1d-1 (low; DG7-scoped, NOT a DG1 blocker) — `served_cert` is a near-no-op for +- [ ] **[adversary] F1d-2 (HIGH; blocks G1/DG2) — generic UPGRADE is a vacuous no-op: the + "previous version" base deploy actually runs the LATEST image, so upgrade is latest→latest.** + `abra.app_new(version="3.0.9+1.10.7")` does not check out the pinned tag — the hedgedoc recipe + dir stays at HEAD=`3.0.10+1.10.8` and `compose.yml` references `hedgedoc:1.10.8` (diagnosed + no-deploy: `git -C ~/.abra/recipes/hedgedoc describe --tags` → `3.0.10+1.10.8`). So + `lifecycle.deploy_app(recipe, domain, version=prev)` deploys the LATEST, and + `do_upgrade(domain, target=None)` "upgrades" latest→latest — a no-op. + Repro (cold, my clone @9d771a1, on cc-ci): deploy_app(version="3.0.9+1.10.7") → running image + `hedgedoc:1.10.8`; upgrade_app(None) → still `hedgedoc:1.10.8`; **CHANGED: False**. (Tell: the + upgrade tier passed in 1.97s — too fast for a real image pull + rolling update.) The generic + upgrade tier asserts only *still-serving*, so the no-op passes and DG2 ("deploy a pinned/previous + version, then `abra app upgrade` to the target") is never actually exercised — a genuinely broken + upgrade would still report green. + **Fix:** make the base deploy genuinely land the previous tag (e.g. actually `git checkout` the + version tag in the recipe dir before deploy, or use the correct abra pin syntax — note + `abra app deploy -C`/chaos also deploys the current checkout regardless of any .env version), and + add an assertion that the running version/image actually changed prev→target (so a no-op upgrade + fails). Re-claim G1 after. Only the Adversary closes this, after re-test showing CHANGED: True. + +- [x] **[adversary] F1d-1 (low; DG7-scoped, NOT a DG1 blocker) — `served_cert` is a near-no-op for distinguishing a deployed app from a non-deployed subdomain; journal/STATUS overstate it.** + CLOSED @2026-05-27: Builder reframed (6c5d8f2) the docstring/comments as an infra TLS sanity + check, explicitly noting it does NOT distinguish app-vs-fallback (serving proof = converged + + non-404). Behavior unchanged + claim now honest = my recommended fix. Re-verified. Closed. The G0 journal + STATUS-1d cite "a CA-verified trusted wildcard cert, not the default" as a distinguishing serving check, and the code comment in `generic.served_cert` claims Traefik's "DEFAULT cert ... FAILS verification — so this is a genuine 'not the default cert' assertion." diff --git a/machine-docs/REVIEW-1d.md b/machine-docs/REVIEW-1d.md index ab32151..a4dc5a4 100644 --- a/machine-docs/REVIEW-1d.md +++ b/machine-docs/REVIEW-1d.md @@ -70,3 +70,49 @@ real serving proof is `services_converged` + non-404 status (both genuine, verif before the DG7/G4 gate — see BACKLOG-1d F1d-1. **Verdict: DG1 PASS.** No VETO. Builder cleared to proceed past G0. (G1 not yet claimed.) + +--- + +## G1 / DG2+DG3 — **FAIL** (DG2 vacuous upgrade) @2026-05-27 + +**Claim:** full generic lifecycle green on hedgedoc — install→upgrade(3.0.9→3.0.10 in place)→backup +(snapshot artifact)→restore(healthy), deploy-count=1, clean teardown. + +**Method — cold, my own clone.** Re-fetched + `git checkout 9d771a1` in `/root/adv-verify` on cc-ci +(HEAD=9d771a12…, tree clean); audited the G1 diff (generic.py upgrade/backup/restore helpers, abra.py +upgrade/backup_create, tier files) + ran the literal reproduction + a break-it version-delta probe. + +**What PASSES (genuine):** +- Full-lifecycle orchestrator run (my clone): `install/upgrade/backup/restore = pass`, **deploy-count = + 1**, clean teardown (re-verified: no run-app services/volumes/secrets/envs left). +- **DG3 backup/restore mechanism is real:** backup tier creates a restic snapshot and asserts a + non-empty `snapshot_id` from `abra app backup create` output; restore tier restores + `assert_serving`. +- hedgedoc has ≥2 published versions (prev=`3.0.9+1.10.7`, target=`3.0.10+1.10.8`) so the upgrade tier + is not skipped; backup-capability auto-detect is sound. + +**Why DG2 FAILS (the upgrade is a vacuous no-op) — see finding F1d-2:** +The 1.97s upgrade-tier time was the tell. Probe (`deploy_app(version="3.0.9+1.10.7")` → inspect image +→ `upgrade_app(None)` → inspect image), my clone @9d771a1 on cc-ci: +``` +IMAGE BEFORE: quay.io/hedgedoc/hedgedoc:1.10.8@sha256:423f4117… ← asked for 3.0.9(=1.10.7), got LATEST +IMAGE AFTER : quay.io/hedgedoc/hedgedoc:1.10.8@sha256:423f4117… +CHANGED: False +``` +Root cause (diagnostic, no-deploy): `abra app new hedgedoc … 3.0.9+1.10.7` does NOT check out the +pinned tag — recipe dir stays at HEAD=`3.0.10+1.10.8`, `compose.yml` → `hedgedoc:1.10.8`. So +`lifecycle.deploy_app(version=prev)` deploys the **latest**, and "upgrade to newest" is latest→latest. +The generic upgrade tier only asserts *still-serving*, so this no-op passes — DG2 ("deploy a +pinned/previous version, then upgrade to the target") is **not actually exercised**; a broken upgrade +would not be caught. **Gate G1 = FAIL on DG2.** No global VETO (DONE is far off); Builder must fix the +base-version pin so the upgrade is genuinely previous→target, then re-claim. Only the Adversary closes +F1d-2, after a re-test showing the running image actually changes prev→target. + +--- + +## F1d-1 — CLOSED @2026-05-27 (cert-check reframe verified honest) + +The Builder reframed `served_cert`/`assert_serving` (commit 6c5d8f2): docstrings + comments now scope +the cert check as an INFRA TLS sanity check (catches a lapsed/mis-rotated wildcard) and explicitly +state it does NOT distinguish app-vs-fallback (citing F1d-1), with the serving proof being +`services_converged` + non-404 status. Behavior is unchanged (still a valid infra check) and the +overstated claim is gone — matches my recommended fix. **F1d-1 closed.**