railiance-apps/docs/assessments/cust81-private-reader/apps-owner-review-r2.md

Railiance apps preparation review — CUST81 private metadata reader R2

Reviewer: delegated railiance-apps preparation worker, supervised local preparation assignment. No promotion evidence or existing own-scope supervision record was found; the descriptive preparation record grants no runtime authority. This is an S5 release-contract review grounded in INTENT principles 1–5 (workloads, release contracts, repeatable operations, explicit S3 handoff, verified health). It is not a founder decision, independent platform credential review or reuse application source review. No live changes, commits, pushes, hub writes, image publishes, login or credential retrieval occurred.

Disposition: approved for integration as local preparation only; live promotion blocked. Canonical review disposition: approved. This accepts the bounded S5 proposal and its explicit runtime gates, not live execution or another owner’s review.

Proposed changes and owner boundaries

The chart accepts an optional immutable image digest, adds a non-secret exact REUSE_SURFACE_AUTH_SOURCE_ALLOWLIST environment binding, and fails rendering when a nonempty allowlist lacks an immutable digest. Schema checks enforce HTTPS allowlist entries and valid digest syntax. Production values continue using their existing main-6cbc862 tag; production ExternalSecret is unchanged. The preparation override contains exactly 14 reviewed pinned metadata URLs and an empty digest deliberately preventing deployment. A synthetic all-zero digest in local tests is not an image and must never be promoted.

The proposed phase-B ExternalSecret preserves existing two keys, target metadata and existing openbao-reuse ClusterSecretStore, adding only REUSE_SURFACE_FORGEJO_SOURCE_READ_TOKEN from workloads/reuse/reuse-surface/forgejo-source-read:FORGEJO_SOURCE_TOKEN. Platform owns the dedicated KV path/policy/store read scope, CCR-2026-0046 and credential issuance; apps neither provisions nor consumes an admin credential.

Digest presence cannot prove the hardened application is included. The reuse owner must provide published build digest, source revision, tests and review binding both authenticated redirect rejection and exact environment-name/URL credential routing. A reader must not reach the existing vulnerable runtime.

Ordered promotion gates — not executed

1. Confirm own-scope supervision and founder change approval, reviewed CCR, exact seven-source owner consent packet and scoped Forgejo read-only issuer receipt. Integrate provisional RAPPS-WP-0017 through root owner coordination.
2. Run metadata inventory helper with an explicitly verified railiance01 kubeconfig; compare existing authenticated registrations with newly fail-closed image behavior. The helper reads only SQLite registration metadata, never env/Secrets, captures command errors and refuses unsafe URLs. If it refuses, resolve via the source owner without emitting raw objects. Any existing authenticated source requires separately reviewed exact URL bindings including capability entry URLs before promotion; do not silently orphan sources or broaden the 14-URL map. Missing inventory blocks phase A. Store only safe names, counts and validated metadata URLs.
3. Read live release image/revision, replica state, PVC storage/access modes and readiness. Confirm node external IP 92.205.62.239, not retired coulombcore. Record requested CPU/memory headroom and pending pods before rollout. Existing API requests 100m CPU/256Mi, surge1 requires that much additional allocatable capacity; landing unchanged. Confirm the existing PVC supports simultaneous pod scheduling/mount on this single node; stop if RWO/RWOP or mount conflicts prevent it. No rollout strategy/resource/PVC changes are proposed. Do not change other workloads merely to obtain capacity.
4. Once a real reviewed digest exists, fill the preparation values; render exact chart with production values plus proposal overrides. Server dry-run and client diff must cover every rendered chart object and the phase-B ESO manifest. Preserve stderr in memory and emit sanitized status only; never print live Secrets, Helm secret values, annotations or raw API failures. Existing release owner and any Argo adoption must be verified before choosing owner Helm upgrade versus GitOps sync; neither is executed here.
5. Phase A: approved release of hardened digest plus approved allowlist, with existing ESO fields only. Owner Helm path must use atomic upgrade, timeout and wait; verify actual running imageID matches digest, API health/probes, public federation baseline63 and credential-routing refusal/redirect tests. Deployment failure blocks phase B. Database/PVC remains unchanged. Collect a separately approved safe backup/recovery receipt before any risky live release.
6. Phase B: after verified phase A, execute reviewed platform credential action and ESO reader mapping. Verify only ESO condition/status and key-presence booleans via approved suppressing helpers, then restart/sync the hardened workload so envFrom obtains the reader. Never dump Secret or process env.
7. Reuse owner runs native exact-byte authenticated proof for all14 URLs and seven capability entries using pinned consent hashes. Only then register seven sources through the scoped write route and verify hosted70/70, no duplicates/conflicting IDs and public federation preserves all63.

Rollback contract

Before execution capture previous approved release revision, digest/tag and safe configuration, public discovery baseline and database recovery receipt. If phase A fails before credential delivery, atomic restore of previous release is safe because no reader has been supplied. After phase B, never downgrade to vulnerable runtime with reader still available: revoke the dedicated reader at Forgejo/OpenBao via credential owner, remove phase-B ESO mapping and materialized reader key through reviewed silent maintenance, restart current hardened pods, verify absence/revocation, then restore prior approved chart/image only if needed. Metadata registrations may remain inaccessible until re-established; record the regression explicitly. Do not roll back the PVC or use stale tokens as recovery.

Local evidence and limitations

helm lint charts/reuse-surface -f helm/reuse-surface-values.yaml passed. python3 docs/assessments/cust81-private-reader/verify_preparation.py passed ten checks, including exact14 roundtrip, digest/schema refusal, retention of current strategy/resources/PVC, correct isolated ESO mapping, metadata URL sanitization and subprocess error suppression. local-verification-r2.json contains command statuses without raw output. No cluster inventory, resource headroom, server dry-run/diff, image publish, live approval or native fetch has been proven.

Revision history — same proposal, no second trial

R1 root review found the inventory SQL incorrectly selected $.index_url rather than the native HubStore registration field $.url. R1's local checks did not exercise the pod SQL and therefore missed this defect. R1 must not be executed; it remains preserved in the root assembly archive. R2 selects $.url and tests the exact read-only pod SQL against a real SQLite registration payload containing repo, url, auth_env, timestamps and an unrelated sentinel description, plus an anonymous registration. Only expected names/URL emerge; rows remain unchanged. R2 also accepts canonical Forgejo raw branch/commit/tag index routes while still refusing userinfo, non-HTTPS, credentials in queries and fragments. Untrusted successful subprocess output is refused without raw echo, as are failures. No live inventory command has run. This corrective refinement is the same CUST81-APPS-PRIVATE-READER-RELEASE proposal revision2, not an unchanged success.