Skip to content

fix(release): distinguish ZIP64 locators from wheel comments - #218

Draft
seonghobae wants to merge 3 commits into
mainfrom
release/fix-sbom-zip64-comment-main-7faf
Draft

fix(release): distinguish ZIP64 locators from wheel comments#218
seonghobae wants to merge 3 commits into
mainfrom
release/fix-sbom-zip64-comment-main-7faf

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

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 stdlib zipfile repeated 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:

  • recognize a ZIP64 locator only when its fields point to a correctly framed ZIP64 EOCD record immediately before the locator;
  • retain the existing single-disk, entry-count, central-directory, sentinel, ZIP64-extra, archive-member and finite-resource checks;
  • prove whether a locator-shaped suffix is inside the final central-directory member comment while streaming the already-bounded directory;
  • when that exact safe condition occurs, parse a temporary stdlib-only snapshot whose four locator-signature bytes are masked, leaving the original artifact and its digest unchanged; and
  • close the temporary parser snapshot deterministically.

Test-first evidence

RED

59057c6993ef725fb8b961e7844ce4ba8423b24d added only tests/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

54a26dec8c28a617e1fa9d15745691bf86b87340 replaced EgressWeave's signature-only preflight with structural ZIP64 framing. Exact-head CI still failed. The failing stack moved into Python zipfile._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

473e7be592c45e059ab770b8cc9701171e339e1a adds the bounded stdlib-parser compatibility snapshot after structural EgressWeave validation. On the exact current head:

  • repository CI run 31677261063 completed successfully;
  • package build/verification completed successfully;
  • Python 3.14.6 passed all 1,026 tests;
  • owned production coverage is exactly 100% statement and branch coverage: 1,758 statements, 0 missed; 588 branches, 0 partial;
  • ruff, hourly product-guard self-test, and compileall passed; and
  • the Python 3.10-3.14 matrix is covered by the successful exact-head CI run.

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

  • No archive extraction.
  • No acceptance of structurally proven ZIP64 or multi-disk archives.
  • No modification of the evidence artifact used for hashing or identity checks.
  • No runtime egress behavior change.
  • No new dependency, secret, reviewer, or publication credential.

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.

@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0e2634fd-68c3-4c54-a330-4e9ef9f6ed67

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Contributor Author

@coderabbitai review
@opencode-agent review
@cwl-noema-review review

Review exact current head 473e7be592c45e059ab770b8cc9701171e339e1a only against live protected main 7faf7a3b8a47980113982914000e724ab6a6cda5. Validate that ZIP64 locator bytes are recognized only with structurally valid locator-to-ZIP64-EOCD framing, legitimate final central-directory member comments are accepted without mutating the original artifact, stdlib-parser compatibility uses a bounded temporary snapshot, actual ZIP64 remains fail-closed, and existing artifact-size/member/metadata checks are preserved. Submit a real current-head source-review verdict; do not mutate, merge, or treat wrapper/check transport as approval.

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Rate Limit Exceeded

@seonghobae have exceeded the limit for the number of chat messages per hour. Please wait 25 minutes and 41 seconds before sending another message.

@seonghobae seonghobae left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

@cwl-noema-review review

Review exact current head 473e7be592c45e059ab770b8cc9701171e339e1a against protected main@7faf7a3b8a47980113982914000e724ab6a6cda5. Validate structural ZIP64 locator recognition, the legal final-member-comment false-positive path, bounded central-directory parsing, original-artifact digest preservation, the temporary parser-snapshot mutation boundary and deterministic cleanup. Submit a formal independent verdict only for this head. Do not mutate, merge, or promote the Security Scan wrapper while its actual pinned Dependency Review action is skipped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant