From 98276124e5a4dcc0d898b33d2349b8c599f9a2dc Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Tue, 9 Jun 2026 15:31:20 +0000 Subject: [PATCH] ideas: isolate the upgrader's direct deploy onto separate infra (can't tamper with tests) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The step-2b direct deploy-and-inspect runs on the cc-ci server's own swarm today, so the upgrader holds write access to the host that owns the tests + CI verdict — a trust hole (could hack the tests). Parked idea: a dedicated throwaway test server with scoped creds, so the upgrader can deploy+inspect but not modify the gate. Co-Authored-By: Claude Opus 4.8 --- cc-ci-plan/IDEAS.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/cc-ci-plan/IDEAS.md b/cc-ci-plan/IDEAS.md index 025dcc5..4e10ce7 100644 --- a/cc-ci-plan/IDEAS.md +++ b/cc-ci-plan/IDEAS.md @@ -130,3 +130,32 @@ item into the project `BACKLOG.md` as `[idea]` if/when it becomes relevant. - *When to revisit:* after the server regression canaries land (want self-tests before re-architecting the thing that runs them). Treat as a design spike — the runner's Swarm-access model (socket / DinD / separate Swarm) is the decision that drives everything else. + +- [ ] **Move the upgrader's direct deploy-and-inspect onto SEPARATE infra (isolate it from the cc-ci + server, so it can't tamper with the tests).** *(operator-flagged 2026-06-09)* + The upgrader now has a direct deploy-and-inspect dev loop (`/recipe-upgrade` step 2b): it deploys the + WIP recipe with `abra app deploy --chaos` and reads `docker service logs` to debug an upgrade before + the `!testme` CI gate. **Today that runs on the cc-ci server's own local swarm** — i.e. the autonomous + upgrader (and its subagents) hold `ssh cc-ci` + root + docker + abra on the **same host that owns the + harness, the recipe tests, and the CI verdict**. That's a trust-isolation hole: an agent with write + access to the box that gates it could — by accident, prompt-injection, or reward-hacking — **edit the + tests/harness to make a failing upgrade "pass"** ("hacking the tests"). We can't be fully sure the gate + is honest while the thing being gated can modify the gate. + - *Idea:* give the upgrader a **dedicated, throwaway test server** (a real `cctest`-style host, like + recipe-maintainer's `cctest.autonomic.zone`) for the step-2b deploy/inspect loop, reached with + **scoped, test-only credentials** (its own SSH key/abra context — blast radius limited to that host, + per recipe-maintainer's `test-ssh/` model). The upgrader gets all the live-log feedback there and has + **no write access to the cc-ci server**. The cc-ci `!testme` CI stays the independent, tamper-proof + gate — run by infra the upgrader cannot touch — so a GREEN verdict means the tests it can't edit + passed. + - *Pros:* the CI gate becomes trustworthy under an autonomous/untrusted upgrader (least-privilege: + the agent can deploy + inspect but not alter the harness/tests/verdict); cleaner separation of + "develop the upgrade" (test server) from "verify the upgrade" (cc-ci CI); matches recipe-maintainer's + limited-blast-radius `test-ssh/` posture. + - *Cons / crux:* new infra to provision + keep current (a second Co-op Cloud host or VM, abra + `server add`, scoped SSH creds, its own teardown/orphan-sweep); cost + maintenance; and the harness + deploy path may assume `--server default`/local, so the per-run CI deploys vs the upgrader's + test-server deploys need a clear split. Until then, the local-swarm dev loop + the orphan-sweep are + the interim posture (functional, but NOT isolation-safe against a malicious/compromised upgrader). + - *When to revisit:* before running the upgrader fully unattended/untrusted at scale, or alongside the + "package cc-ci as a recipe" spike above (both hinge on a separate disposable test Swarm). *Added:* 2026-06-09.