pdurlej/platform

Fork 0

fix(platformctl): scrub apply status artifacts #638

Merged

pdurlej merged 1 commit from codex/m06-scrub-apply-status-artifacts into main

2026-05-30 14:36:20 +02:00

codex commented

2026-05-30 14:23:09 +02:00

Collaborator

Canary status: missing — fire canary 3+3 manually before merge

Canary Context Pack

Product story

Apply status artifacts are durable evidence. They should be safe to keep, copy, and inspect even when remote stderr/stdout or exception messages include token-shaped provider values.

What changed

Added a targeted status-artifact scrub pass for nested preflight, remote, and error fields before writing *.status.json.

Why it changed

Issue #206 closes the redaction chain after #199 and #200. It prevents token-like values from being persisted in status JSON while keeping apply result semantics unchanged.

Files touched

control-plane/platformctl/apply.py
control-plane/platformctl/tests/test_apply_phase3.py

Relevant context

Issue #206: STATUS-JSON-TOKEN-SCRUB-01
Issue #194 grind order: redaction before provenance/adversarial matrix

Runtime evidence

No runtime mutation. Local validation only.

Known constraints

The scrub is intentionally scoped to status artifact serialization. It does not mutate the in-memory apply result object.

Explicit out-of-scope

No new provider redaction framework
No provenance/adversarial matrix changes (#192/#193/#194 later)
No runtime apply or service restart

Requested decision

Approve merge if tests and Patchwarden checks are green.

Merge blockers

Status artifacts can persist token-like values in nested preflight, remote, or error
Approved SHA fields are accidentally redacted
Existing apply behavior changes beyond artifact persistence

Spec sources read

Forgejo issue #206
docs/forgejo-agent-operations.md
control-plane/platformctl/apply.py
control-plane/platformctl/tests/test_apply_phase3.py
control-plane/platformctl/tests/test_apply_env_file.py

Validation

PYTHONPATH=control-plane control-plane/.venv/bin/python -m pytest control-plane/platformctl/tests/test_apply_phase3.py control-plane/platformctl/tests/test_apply_env_file.py — 68 passed
PYTHONPATH=control-plane control-plane/.venv/bin/python -m platformctl.cli validate all --json — passed

Closes #206

Canary status: missing — fire canary 3+3 manually before merge ## Canary Context Pack ### Product story Apply status artifacts are durable evidence. They should be safe to keep, copy, and inspect even when remote stderr/stdout or exception messages include token-shaped provider values. ### What changed Added a targeted status-artifact scrub pass for nested `preflight`, `remote`, and `error` fields before writing `*.status.json`. ### Why it changed Issue #206 closes the redaction chain after #199 and #200. It prevents token-like values from being persisted in status JSON while keeping apply result semantics unchanged. ### Files touched - `control-plane/platformctl/apply.py` - `control-plane/platformctl/tests/test_apply_phase3.py` ### Relevant context - Issue #206: STATUS-JSON-TOKEN-SCRUB-01 - Issue #194 grind order: redaction before provenance/adversarial matrix ### Runtime evidence No runtime mutation. Local validation only. ### Known constraints The scrub is intentionally scoped to status artifact serialization. It does not mutate the in-memory apply result object. ### Explicit out-of-scope - No new provider redaction framework - No provenance/adversarial matrix changes (#192/#193/#194 later) - No runtime apply or service restart ### Requested decision Approve merge if tests and Patchwarden checks are green. ### Merge blockers - Status artifacts can persist token-like values in nested `preflight`, `remote`, or `error` - Approved SHA fields are accidentally redacted - Existing apply behavior changes beyond artifact persistence ## Spec sources read - Forgejo issue #206 - `docs/forgejo-agent-operations.md` - `control-plane/platformctl/apply.py` - `control-plane/platformctl/tests/test_apply_phase3.py` - `control-plane/platformctl/tests/test_apply_env_file.py` ## Validation - `PYTHONPATH=control-plane control-plane/.venv/bin/python -m pytest control-plane/platformctl/tests/test_apply_phase3.py control-plane/platformctl/tests/test_apply_env_file.py` — 68 passed - `PYTHONPATH=control-plane control-plane/.venv/bin/python -m platformctl.cli validate all --json` — passed Closes #206

codex added 1 commit

2026-05-30 14:23:10 +02:00

fix(platformctl): scrub apply status artifacts

python-ci / Python 3.13 (pull_request) Successful in 45s

Details

base-is-main / guard (pull_request) Successful in 1s

Details

patchwarden-pr-sanity / collect-diff (pull_request) Successful in 5s

Details

canary-required / canary (pull_request) Successful in 15s

Details

canary-required / collect-diff (pull_request) Successful in 5s

Details

patchwarden-client-dry-run / collect-diff (pull_request) Successful in 5s

Details

platformctl plan / auto-apply scope (pull_request) Successful in 25s

Details

pyfallow / Pyfallow gate (control-plane) (pull_request) Successful in 23s

Details

python-ci / Python 3.11 (pull_request) Successful in 45s

Details

python-ci / Python 3.12 (pull_request) Successful in 45s

Details

patchwarden-client-dry-run / dry-run (pull_request) Successful in 24s

Details

patchwarden-pr-sanity / sanity (pull_request) Successful in 3m14s

Details

8cf1ba27a6

codex added the

class/security-sensitive

label

2026-05-30 14:23:10 +02:00

codex commented

2026-05-30 14:29:35 +02:00

Author

Collaborator

Patchwarden PR sanity

Status: eligible_sanity_clean
PR: 638
Commit: 8cf1ba27a612f07b94740d06e69a11d75638f95f
Security-sensitive label: present
Authority: advisory model review plus deterministic blockers only
3+3 canary: still alive; this does not replace it

Deterministic findings

info sensitive-path-touched Sensitive path touched — control-plane/platformctl/apply.py
- Evidence: control-plane/platformctl/apply.py
- Next: Route through the existing 3+3/risk-tier process; model review remains advisory.

Model reviewers

`global-glm` / `glm-5.1:cloud`

Status: ok
Verdict: OK
medium 40-char hex regex may redact legitimate SHAs in error/remote/preflight fields
- Evidence: In control-plane/platformctl/apply.py, the pattern (?<![A-Fa-f0-9])[A-Fa-f0-9]{40}(?![A-Fa-f0-9])matches any standalone 40-char hex string inpreflight, remote, or error fields. If a git commit SHA or other legitimate 40-char hex i
- Next: Consider documenting this trade-off in code comments or ADR: status artifacts prioritize security (preventing token leakage) over preserving diagnostic SHAs in remote output. If SHA preservation in error messages becomes critical, a whitelist or context-aware approach could be added later.

`global-deepseek` / `deepseek-v4-pro:cloud`

Status: ok
Verdict: OK
low Overly broad 40-char hex redaction may mask non-token SHAs in nested fields
- Evidence: control-plane/platformctl/apply.py: new regex (?<![A-Fa-f0-9])[A-Fa-f0-9]{40}(?![A-Fa-f0-9])matches any 40-char hex string, not only tokens. Applied topreflight, remote, error fields. Legitimate commit SHAs or other hex identifier
- Next: Consider narrowing the pattern to known token formats (e.g., with a prefix) or documenting that status artifacts may have false-positive redactions. No functional impact, but could affect forensic inspection.

`redteam` / `kimi-k2.6:cloud`

Status: ok
Verdict: OK
Findings: none

Policy notes

GLM 5.1 + DeepSeek V4 Pro are the operator-required model mix for this bot.
Optional red-team model is enabled only when PLATFORMCTL_PR_SANITY_REDTEAM_MODEL is configured.
Auto-merge is not enabled here.

# Patchwarden PR sanity - Status: `eligible_sanity_clean` - PR: `638` - Commit: `8cf1ba27a612f07b94740d06e69a11d75638f95f` - Security-sensitive label: `present` - Authority: advisory model review plus deterministic blockers only - 3+3 canary: still alive; this does not replace it ## Deterministic findings - **`info` `sensitive-path-touched`** Sensitive path touched — `control-plane/platformctl/apply.py` - Evidence: `control-plane/platformctl/apply.py` - Next: Route through the existing 3+3/risk-tier process; model review remains advisory. ## Model reviewers ### `global-glm` / `glm-5.1:cloud` - Status: `ok` - Verdict: `OK` - **`medium`** 40-char hex regex may redact legitimate SHAs in error/remote/preflight fields - Evidence: `In control-plane/platformctl/apply.py, the pattern `(?<![A-Fa-f0-9])[A-Fa-f0-9]{40}(?![A-Fa-f0-9])` matches any standalone 40-char hex string in `preflight`, `remote`, or `error` fields. If a git commit SHA or other legitimate 40-char hex i` - Next: Consider documenting this trade-off in code comments or ADR: status artifacts prioritize security (preventing token leakage) over preserving diagnostic SHAs in remote output. If SHA preservation in error messages becomes critical, a whitelist or context-aware approach could be added later. ### `global-deepseek` / `deepseek-v4-pro:cloud` - Status: `ok` - Verdict: `OK` - **`low`** Overly broad 40-char hex redaction may mask non-token SHAs in nested fields - Evidence: `control-plane/platformctl/apply.py: new regex `(?<![A-Fa-f0-9])[A-Fa-f0-9]{40}(?![A-Fa-f0-9])` matches any 40-char hex string, not only tokens. Applied to `preflight`, `remote`, `error` fields. Legitimate commit SHAs or other hex identifier` - Next: Consider narrowing the pattern to known token formats (e.g., with a prefix) or documenting that status artifacts may have false-positive redactions. No functional impact, but could affect forensic inspection. ### `redteam` / `kimi-k2.6:cloud` - Status: `ok` - Verdict: `OK` - Findings: none ## Policy notes - GLM 5.1 + DeepSeek V4 Pro are the operator-required model mix for this bot. - Optional red-team model is enabled only when `PLATFORMCTL_PR_SANITY_REDTEAM_MODEL` is configured. - Auto-merge is not enabled here.