fix(release): distinguish ZIP64 locators from wheel comments - #218
fix(release): distinguish ZIP64 locators from wheel comments#218seonghobae wants to merge 3 commits into
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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 |
|
@coderabbitai review Review exact current head |
Rate Limit Exceeded
|
seonghobae
left a comment
There was a problem hiding this comment.
Current-head source review for 473e7be592c45e059ab770b8cc9701171e339e1a found no blocking defect in the two-file ZIP64-locator/comment compatibility scope. The implementation treats a locator as structural only when the exact locator fields frame a valid ZIP64 EOCD record, retains the existing single-disk/non-ZIP64 and finite central-directory checks, masks only the four validated false-positive signature bytes in a temporary stdlib parser snapshot, preserves the original artifact and digest, and deterministically closes the snapshot. This is author-side review evidence only, not independent approval. Keep Draft until corrected central Dependency Review and authoritative Strix evidence execute on the unchanged head and a qualifying independent review is present.
|
@cwl-noema-review review Review exact current head |
Protected-base snapshot
Target branch:
main.Live protected base verified for this PR state:
7faf7a3b8a47980113982914000e724ab6a6cda5.Current implementation head:
473e7be592c45e059ab770b8cc9701171e339e1a.Scope
The release SBOM verifier rejected a legal standard wheel when the final central-directory member comment ended with 20 bytes beginning
PK\x06\x07. The previous preflight treated those raw bytes as sufficient evidence of a ZIP64 locator even though they were part of a member comment. After the first structural preflight correction, Python's stdlibzipfilerepeated the same signature-only locator heuristic and still rejected the archive.This lane now distinguishes ZIP64 structure from legal opaque member-comment bytes without weakening ZIP64 rejection:
Test-first evidence
RED
59057c6993ef725fb8b961e7844ce4ba8423b24dadded onlytests/test_release_sbom_zip64_locator_comment.py. Hosted CI failed on Python 3.10 through 3.14 because the legal locator-shaped member comment was rejected.First RCA boundary
54a26dec8c28a617e1fa9d15745691bf86b87340replaced EgressWeave's signature-only preflight with structural ZIP64 framing. Exact-head CI still failed. The failing stack moved into Pythonzipfile._EndRecData64, proving the remaining false positive came from the stdlib's own 20-byte pre-EOCD ZIP64-locator probe rather than EgressWeave preflight.GREEN implementation
473e7be592c45e059ab770b8cc9701171e339e1aadds the bounded stdlib-parser compatibility snapshot after structural EgressWeave validation. On the exact current head:31677261063completed successfully;SAST Semgrep and Security Scan are still pending/queued on this exact head and are therefore not counted as passing evidence. No formal PR review or inline review thread is currently present. CodeRabbit has skipped review because the PR remains Draft; that status is not treated as review evidence.
Safety / non-goals
Merge state
This PR remains Draft. It must not merge until the exact current head has genuinely passing SAST/security/supply-chain evidence and every applicable live protection/review criterion is satisfied. A green wrapper, skipped semantic step, predecessor-head result, or automated status text is not substituted for missing evidence.
Related: #69.