From 5ccc0d1c34922eea7b3f96ea7130fb50f0c85b2b Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Wed, 10 Jun 2026 19:07:24 +0000 Subject: [PATCH] =?UTF-8?q?note(rcust):=20interim=20pre-review=20of=20froz?= =?UTF-8?q?en=20P5=20(68954be)=20=E2=80=94=20cold=20unit=20191=20+=20lint?= =?UTF-8?q?=20PASS=20reproduced;=20manifest=20exposes=20NO=20generated/rea?= =?UTF-8?q?l=20secrets=20(HC2-honoring,=20pure=20presentation);=20one=20no?= =?UTF-8?q?n-blocking=20heads-up=20re=20plausible=20SECRET=5FKEY=5FBASE=20?= =?UTF-8?q?public-dummy=20on=20dashboard=20(NOT=20an=20M1=20verdict)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- REVIEW-rcust.md | 51 +++++++++++++++++++++++++++++++++++ machine-docs/BUILDER-INBOX.md | 20 ++++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 machine-docs/BUILDER-INBOX.md diff --git a/REVIEW-rcust.md b/REVIEW-rcust.md index 4dd0b12..a4c31bc 100644 --- a/REVIEW-rcust.md +++ b/REVIEW-rcust.md @@ -143,3 +143,54 @@ Net: P1+P2+P3+P4 all clean under cold adversarial probing; both halves of every final coverage re-diff on the COMPLETE branch (P1–P6, all 21 recipes, effective customization set unchanged); recipe-test diffs mechanical-only across the whole branch; HC2/F2-11/generic-floor integrity at the final head. These wait for `claim(rcust): M1`. + +### Interim pre-review of frozen P5 (branch @ 68954be) — @2026-06-10T19:06Z, cold from fresh host clone + +Builder landed P5 (customization manifest) and moved to P6, so P5 is frozen. Pre-reviewed it cold. +**No blocking defect; one secret-SURFACE observation raised (heads-up to Builder, NOT a VETO, NOT +an M1 secret-leak failure).** NOT an M1 verdict. + +Cold acceptance (fresh `git clone` on cc-ci host at 68954be, my own checkout): +- `cc-ci-run -m pytest tests/unit -q` → **191 passed** (exact match to claim). +- `nix develop .#lint --command scripts/lint.sh` → **lint: PASS**. + +Primary adversarial target — SECRET LEAKAGE via the new manifest surface (D-gate: published logs + +dashboard contain NO secrets, incl. generated app passwords): +1. **Generated/runtime secrets — NOT exposed (gate holds).** `manifest.build` collects only: + `meta_non_default` (static recipe_meta), hook NAMES (pre-ops/install_steps.sh/compose.ccci.yml), + overlay FILENAMES, custom-test COUNTS, and env-override KEY names (printed `KEY=1`, value never + rendered). It never touches `deps` (client_secret), `op_state`, abra-generated app passwords, or + any env VALUE. The cardinal concern — generated app passwords on the dashboard — is structurally + absent from this surface. +2. **Cold all-recipes sweep.** Built+rendered the manifest for all 21 recipes on the host; grepped + the rendered blocks AND the results.json `customization` payload for secret/password/token/key/ + credential and for any 32+ char high-entropy string. The ONLY hit, across every recipe, is + plausible's `EXTRA_ENV.SECRET_KEY_BASE` = + `"ccciplausibletestkeybase64charsexactlyforCIephemeral4567890123"`. +3. **OBSERVATION (not a leak):** that value is a HARDCODED, committed, PUBLIC dummy CI constant + (tests/plausible/recipe_meta.py, in the open-source repo) — not a generated or real secret. + `meta_non_default` dumps EXTRA_ENV literal dicts verbatim into the log AND results.json (→ + dashboard), so a field literally named `SECRET_KEY_BASE` with a value now appears on the + dashboard. No real secret is exposed (it's public), so this is NOT a D-gate failure and does NOT + block P5. BUT it's a standing surface: (a) a dashboard secret-scan gets a true-positive-shaped + hit on a public dummy (noise that could mask a real leak), and (b) if any recipe ever set a real + secret-ish literal in a meta dict, the manifest would surface it unredacted. Flagged to Builder + via BUILDER-INBOX as a heads-up to consider redacting values of sensitive-named meta keys before + M1. Will re-examine on the real dashboard at the M1 cold-verify. +4. **HC2-honoring — confirmed.** Manifest routes ALL repo-local reads through `discovery._gated` + (ops.py loop direct; `install_steps`/`resolve_overlay_op`/`custom_tests` each call `_gated` + internally). An unapproved repo-local recipe contributes nothing to the manifest. +5. **Pure presentation — holds.** `build()` only reads files/env and returns a dict; `render()` + formats a string. Called at run_recipe_ci.py:889-890 (print) + embedded at :1261 into results; + no state mutation, no verdict influence. `_jsonable` renders callables as `''` (so a + callable EXTRA_ENV/READY_PROBE never leaks closure internals) and tuples→lists for JSON. + +Net: P1–P5 all clean under cold adversarial probing; every phase claim (unit count + lint) +reproduced cold. No findings filed; no VETO. One non-blocking secret-surface heads-up sent. + +**Still UNVERIFIED for M1:** P6 (docs); `pytest tests/concurrency -q` cold; R2 end-to-end via the +real orchestrator screenshot path; final coverage re-diff on the COMPLETE branch (all 21 recipes, +effective customization unchanged); recipe-test diffs mechanical-only across the whole branch; +HC2/F2-11/generic-floor integrity at final head; AND — at the M1 dashboard check — confirm the +SECRET_KEY_BASE-named field on the real dashboard is the accepted public dummy (or redacted). +These wait for `claim(rcust): M1`. diff --git a/machine-docs/BUILDER-INBOX.md b/machine-docs/BUILDER-INBOX.md new file mode 100644 index 0000000..1e0df4f --- /dev/null +++ b/machine-docs/BUILDER-INBOX.md @@ -0,0 +1,20 @@ + +## [adversary heads-up @2026-06-10T19:06Z] P5 manifest — sensitive-named meta values on dashboard (non-blocking) + +NOT a gate FAIL, NOT a VETO — P5 is clean and I logged a PASS-equivalent pre-review. Heads-up for +your consideration before M1: + +`manifest.build` dumps `meta_non_default` dict VALUES verbatim into the run log AND results.json +(→ dashboard). Across all 21 recipes the only secret-shaped value is plausible's +`EXTRA_ENV.SECRET_KEY_BASE` = "ccciplausibletestkeybase64charsexactlyforCIephemeral4567890123". +That's a committed PUBLIC dummy CI constant, so no real secret leaks — fine today. + +But the dashboard now shows a field literally named `SECRET_KEY_BASE` with a value. Consider, at +your discretion: + - redacting values of meta keys whose name matches a sensitive pattern + (SECRET|PASSWORD|TOKEN|KEY|CREDENTIAL) in the manifest (render the key, mask the value), OR + - documenting in the manifest/docs that meta values are repo-public-by-construction so a + secret-scan hit on the dashboard is expected noise for that one field. + +Either is acceptable to me. I'll re-check the real dashboard for this at the M1 cold-verify. No +action required to keep P5 green.