fix(osv): preserve immutable direct-source provenance - #1158
Conversation
|
Warning Review limit reached
Next review available in: 46 minutes Limit details: You’ve used the included review currently available. 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?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day 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 (8)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
|
@opencode-agent review exact current head |
|
@opencode-agent Keep this PR Draft and repair the current exact head
Also remove the self-trust exception in |
|
Revalidated PR #1158 after repairing the current-head provenance contract. Root-cause fixes:
Exact-head proof:
Please rerun independent review and all protected Checks for this exact head. The PR remains subject to branch protection; no merge is claimed. |
|
@opencode-agent review exact current head |
|
@opencode-agent review this exact current HEAD. Use the current commit SHA, current Checks, and current diff; do not reuse prior approvals or prior-head evidence. |
|
Inkspan downstream canary is ready for this existing owner lane; no consumer-side suppression/workaround has been introduced. Fresh bindings before this note:
After this exact owner repair integrates into protected |
|
Security root-cause fix at current head e2c0031: malformed UTF-8 is now rejected at the shared text-input boundary with an explicit fail-closed ValueError, covering lockfile and JSON audit/results inputs. Added regression coverage; local 15 tests, Ruff, compileall, and diff checks passed. Please run the independent current-head review and required checks for this exact SHA. |
|
@opencode-agent please review current HEAD e2c0031 for PR #1158; focus on malformed input handling, fail-closed provenance, and security regressions. |
|
Exact-head repair pushed as eb7efe5 from fca5cd1. The live branch had already incorporated the scheduler assertion correction; its remaining hashed audit lock was still pip 26.1.2. Updated only that lock to pip 26.2.1 with exact hashes. Verification: 77 tests and 53 subtests for direct-source reconciliation and required workflow contracts passed; pip-audit reported no known vulnerabilities; git diff check passed. Hosted checks and exact-head independent approval must be re-evaluated for eb7efe5. No bypass or force push was used. |
|
@claude Please review exact current head |
|
Please run the formal current-head review at exact SHA ; this central OSV provenance repair is required before dependent LineageWeave security Checks can be trusted.\n\nThe required merge gate remains protected; no self-approval or bypass is requested. |
|
Please run the formal current-head review at exact SHA c45a776; this central OSV provenance repair is required before dependent LineageWeave security Checks can be trusted. The required merge gate remains protected; no self-approval or bypass is requested. |
|
Exact-head integration note for c45a776: contextual-orchestrator #820 run 32514293613 confirmed scanner exit 0 followed by failure of the deprecated output-file contract. This PR is the normal central repair path for LineageWeave #383, contextual-orchestrator #818/#820, and GRC #51. Please preserve the exact-head and independent approval gates; rerun downstream security checks only after this repair is protected. |
|
Exact evidence from LineageWeave #383 and contextual-orchestrator #820/#818 confirms the shared OSV failure was not a package finding: osv-scanner v2.3.8 returned exit 0, warned that |
|
Current head f61a879 has passed the direct-source provenance contract and exact-path policy; remaining checks are still running. Please perform an independent formal review of this shared-workflow change before protected merge, since the OSV correction gates downstream consumer checks #383 and #820. |
Exact-head maintainer audit
|
|
Consumer verification: contextual-orchestrator#818 exact head |
|
@claude Review exact current head |
| def valid_sha512_integrity(value: str) -> bool: | ||
| """Return whether an integrity string contains one exact SHA-512 digest.""" | ||
|
|
||
| if not value.startswith("sha512-"): | ||
| return False | ||
| try: | ||
| decoded = base64.b64decode(value.removeprefix("sha512-"), validate=True) | ||
| except (ValueError, binascii.Error): | ||
| return False | ||
| return len(decoded) == 64 |
There was a problem hiding this comment.
📝 Info: SHA-512 integrity gate is well-formedness only
valid_sha512_integrity (osv_direct_source_reconcile.py) only checks that the integrity string decodes to 64 bytes. It does not verify the digest against a real artifact. Reconciliation trusts the lockfile-declared URL/integrity shape and OSV's reported version rather than re-verifying the tarball.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
@claude Review exact current head against base . Confirm coverage, security, data-loss, and workflow behavior from this head only. Do not self-approve, bypass, force-push, or merge. |
Current-head RCA: integrity must be identity-bound, not only well-formedFresh live-state resolution after central-main movement:
First causal boundary / conflicting propositions. The PR contract says reconciliation is limited to an “exact official immutable” SheetJS release, but current Exact consumer reproduction. Inkspan #318 remains Falsifiable RED acceptance. Keep canonical URL/version and replace integrity with any other valid base64-encoded 64-byte SHA-512 value. The reconciler must retain the advisories as Smallest safe remedy. Bind the governed After the source repair, update/restack the existing owner branch onto then-current protected main without force-push/destructive history, regenerate exact-head required evidence, and correct the PR body to the independently resolved head/base. Only after that repair reaches protected central main should Inkspan #318 receive a fresh Security Scan on unchanged/descendant source. Do not resolve the integrity thread, merge, suppress locally, or transfer predecessor evidence before those conditions are met. |
Closes #1096.
Problem and fail-closed contract
The reusable Security Scan previously passed OSV's npm name/version result to the reporter without preserving direct-tarball URL and integrity evidence. Open-ended npm ranges could therefore attribute already-remediated advisories to an official immutable vendor release.
This repair:
xlsxreleases, including 0.18.x, 0.19.2, and 0.20.1;xlsx@0.20.3provenance whose authoritative affected range excludes it;SCANNER_METADATA_CONFLICTevidence;O_NOFOLLOWand regular-file validation;packagesmap, not provenance-free snapshot duplicates;source.pathfor the governed root lockfile;Exact identity and evidence
c45a776f9ec3be8b35ee105e966100c80b95c2cc.main@fce028b4c3bf8e2e5e4819c1c5622e90cfa6ab39.source.pathenforcement; OSV v2.3.8 rejected the stale--outputflag before the exact--output-filerepair.fca5cd1e3d14418b8a5fc5cd3636815582228457and are now historical. Fresh current-head organization-readiness and exact-artifact SBOM quality runs are terminal success; OSV/Strix and security jobs are running or queued. Pending evidence is non-passing.Consumer acceptance remains a fresh Security Scan on unchanged/descendant Inkspan #318 only after this repair reaches protected main. Queued security/SBOM work and predecessor checks or reviews remain non-passing.