fix(acquisition): authenticate exact deployment evidence bytes - #125
fix(acquisition): authenticate exact deployment evidence bytes#125seonghobae wants to merge 2 commits into
Conversation
|
Warning Review limit reached
Next review available in: 37 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Purpose
Test-first repair for #124. The acquisition deployment-evidence verifier must validate semantics from exact retained bytes and bind the verification-receipt subject digest to those exact bytes rather than replacement-decoded text.
Exact current identity
mainc85d710804139c0697d7ef8fa47d02b1389e6d84;fix/acquisition-deployment-exact-bytes;4d3df316751da0e63ea5466f158587e7a08b5905;10e6636a2e72cc7bfcbc840257fc7eaa3d34d9e4;main, merge base exactly the live protected head;scripts/acquisition-deployment-evidence-audit.mjs,test/acquisition-deployment-evidence-input-integrity.test.ts.RCA -> RED -> GREEN
Protected source read acquisition deployment inputs through
readFileSync(path, "utf8"). That can replacement-decode malformed bytes before JSON/JSONL semantics, whiledeploymentEvidenceSha256was calculated from normalized text. The verifier could therefore bind a receipt to bytes different from the retained subject.The RED regressions keep a valid passing fixture, inject malformed UTF-8 into otherwise valid deployment JSON while deliberately matching the receipt to replacement-decoded text, and separately corrupt the retained attestation bundle. Both malformed retained-byte cases must fail closed.
GREEN separates bounded regular-file byte reads from fatal UTF-8 decoding. JSON/JSONL parsing occurs only after strict decoding, and deployment subject SHA-256 is computed over the exact retained
Buffer. Existing release identity, governance, attestation, signer/OIDC/runner-policy and report semantics remain unchanged.Exact current-head proof
For unchanged current head
10e6636a2e72cc7bfcbc840257fc7eaa3d34d9e4:ci31443312371: terminal success;reviewer-ci31443312390: terminal success;Security Scan31443312357: terminal success;Authority boundary
This is verifier-integrity evidence, not production or acquisition acceptance. It does not create deployment evidence, prove the production environment, cryptographically verify an attestation by itself, choose owner/legal rights, establish revenue, or make Noema acquisition-ready. #120/#121 remain the separate deployment-receipt construction boundary; stale #69 remains the broader acquisition-manifest lineage. Technical GREEN cannot replace live #27 governance or qualifying independent non-author approval under #29.
Related: #5, #27, #29, #40, #68, #120, #121, #124