security: pin mitmproxy image chain + rtk installer (Phase 1 of #20)

[shejnowicz]

Closes #20.

Summary

Removes `latest`-tag supply-chain exposure from sandcat's security-critical image chain. The mitmproxy image sees all agent plaintext and holds real secret values — today every `docker compose pull` silently swaps it for whatever upstream published, and the weekly CI cron overwrites the ghcr `latest` tags that generated projects reference.

What's pinned now (to 12.2.3):

• `mitmproxy/mitmproxy` in the generated `compose-proxy.yml` (provider `none`)
• `ghcr.io/virtuslab/sandcat-mitmproxy-op` / `-pass` in `apply_secret_provider` (secret providers)
• `FROM` in both `images/*/Dockerfile` (via `ARG MITMPROXY_VERSION`, no default)
• rtk installer: script pinned to a commit SHA and binary pinned via `RTK_VERSION=v0.45.0` (rtk's install.sh SHA-256-verifies the download against the release's checksums)

Two-file source of truth, contract-enforced: `SCT_MITMPROXY_VERSION` in `cli/lib/constants.bash` (ships with the CLI) + `MITMPROXY_VERSION` in `images/mitmproxy.env` (consumed by CI). A contract test (`cli/test/compat/mitmproxy_version.bats`) fails CI when they diverge — and `cli-tests.yml` now triggers on `images/mitmproxy.env` too, so a one-sided bump can't slip through. Bump = 2 lines, documented in `cli/README.md`.

CI channel policy (traced across all 5 event buckets in review):

• master push (or manual dispatch on master) → publishes `` + `sha` tags; never moves `latest`
• weekly cron → builds `FROM mitmproxy:latest` and refreshes ONLY the `latest` tag (tracking channel)
• manual dispatch off-master → branch-name + sha tags only — can never overwrite a canonical version tag
• PRs → build-only, no push (unchanged)

Deliberate design choices (for reviewer visibility)

• `latest` refreshes only weekly — master pushes no longer move the ghcr `latest` tags. Chosen deliberately to keep the tracking channel and the pinned channel on separate publishers. Consequence: a Dockerfile hotfix reaches old (`latest`-referencing) projects at the next cron, up to 7 days. If faster reach is ever needed, a channel-select `workflow_dispatch` input is the natural extension.
• Versioned tags are immutable by convention, not cryptographically — digest pinning is a possible Phase 3. Phase 2 (Renovate automation for bumps) is also out of scope here.
• Out of scope: base images (`devcontainers/base`, `debian:trixie-slim` — agent-side, inside the sandbox boundary) and agent CLI installers (self-updating tools).

Merge-day sequencing (important)

The ghcr `12.2.3` tags publish only AFTER this merges (the image workflows trigger on this push). Until both workflows go green (~5-25 min), a freshly generated secret-provider project fails `docker compose up` with a loud, retry-safe `manifest unknown`. Provider `none` is unaffected (the public Docker Hub tag exists). Documented in the bump procedure.

Post-merge checklist: confirm both image workflows published `sandcat-mitmproxy-op:12.2.3` and `-pass:12.2.3`, then smoke-test a 1password-provider project.

Test plan

• Full bats surface green (14 suites), including the new 18-assertion compat suite with the version contract test
• Hands-on integration (provider `none`): fresh project → compose references `mitmproxy/mitmproxy:12.2.3`, placeholder fully resolved → `up -d --build` pulls the pinned tag, all healthy, running container verified on the pinned image, `curl https://github.com\` → 200 through the pinned proxy
• Provider `1password`: generated compose references `ghcr.io/...-op:12.2.3`; `docker compose config` renders (pull deferred to post-merge — tag doesn't exist yet, see sequencing above)
• Local image builds: both Dockerfiles × both build-arg values (`12.2.3`/`latest`) + a pass-cli-pinned build, with in-container smoke checks (`op --version`, `mitmdump --version`, `pass-cli --version`)
• rtk: pinned raw URL serves (HTTP 200); `v0.45.0` verified as a stable (non-prerelease) release matching the pinned commit
• Workflow YAMLs validated; tag policy hand-traced per event in both files (identical expressions)

🤖 Generated with Claude Code

https://claude.ai/code/session_01DFCiFbv1Cpr7yzCU8ftvzZ

[adamw]

I'm not sure I understand the whole latest-tag ceremony, it seems quite complex. Can't we pin the mitmproxy version and simply tag with latest the latest build of our image? Not necessarily using latest mitmproxy inside?

[shejnowicz]

@adamw yes, you are right. The proposal is overcomplicated. I will simplify it the way you described

[shejnowicz]

You're right — and your version is actually safer, not just simpler. The dual-channel design kept ghcr latest tracking upstream mitmproxy for the benefit of already-generated projects that reference it — but that's exactly the supply-chain exposure this PR is meant to close, so preserving it there was backwards.

Reworked as you suggested: every published image now contains the pinned mitmproxy (from images/mitmproxy.env), and latest simply means the newest master build of our image — so pre-pinning projects get the pinned base for free, and the 5-way tag matrix collapses to "master publishes latest + <version> + sha". The weekly cron stays, but as a build-only canary against upstream mitmproxy:latest: a red run flags a breaking upstream release, and nothing is pushed from it. Also rebased onto current master.