Under CASAN_APPROVAL_STRICT=1, a high-risk approval is trusted ONLY when a
REGISTERED reviewer cryptographically signs THIS exact request and their role is
authorized for the action — a plain env-var CASAN_APPROVER is no longer enough.
- approval-sign.sh: reviewer signs assertion
"casan-approval|v1|<action>|<actor>|<input_sha256>|<approver_id>" with their key.
- approval-verify.sh: gate looks up reviewer role+pubkey in reviewers.registry,
enforces role→action authorization, verifies the RSA signature (fail-closed).
- governance-check.sh: strict branch requires a valid signed approval; SoD still
enforced; default (non-strict) env-var path UNCHANGED (baseline preserved).
- reviewers.registry: role-scoped reviewer identity registry (pubkeys off-repo;
production replaces with OIDC/JWT from a real IdP).
- phase-h5-approval-tests.sh: 8 checks — valid/authorized approve; unsigned,
wrong-role, forged-key, unregistered, replay-to-other-request, self-approval
all denied; non-strict backward-compat.
Baselines: run-casan4 35/35, adversarial 44/44. Lifts H5 policy-approval (C4)
2.5 -> ~3.5-4 / 5. Total suites now 6 (+8 checks = 148).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Two comprehensive CI fixes:
1. Adversarial harness flake (PASS=42 FAIL=2, state-dependent):
governance-check.sh re-exported audit-public.pem only when GENERATING a
new signing key. On a CI runner where the off-repo private key PERSISTS
across runs, the checked-out (Vault-signed) audit-public.pem drifted out
of sync with the local re-signing key, so verify-audit-chain.sh rejected a
genuine head ("H5/H2 verifies the genuine signed chain"). Now always
re-export the public key matching the signing key — mirrors the same fix
already applied to tool-audit-lib.sh (c31987c). Reproduced the exact
FAIL=2 locally with a drifted persisted key; now deterministically 44/44.
2. Deploy docker.sock permission denied:
Added a self-healing preflight to deploy-okr that ensures the deploy user
is in the docker group on the web VPS (idempotent, passwordless sudo) and
proves a fresh SSH session can reach the daemon before streaming images.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>