Strip ZIP64 extra field when retagging wheels (#692) - #695
Conversation
`wheel tags` copies each source ZipInfo verbatim, so entries stored past ZIP64_LIMIT carry their central-directory ZIP64 extra field (id 0x0001, holding the header offset) into the rewritten local headers. That field is only valid in the central directory, producing wheels that strict parsers reject (pypa#692). This test forces ZIP64 on small files and asserts no local header of a retagged wheel begins with a 0x0001 extra field.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #695 +/- ##
==========================================
+ Coverage 56.70% 57.15% +0.44%
==========================================
Files 15 15
Lines 1252 1265 +13
==========================================
+ Hits 710 723 +13
Misses 542 542 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
`wheel tags` rewrites a wheel by feeding each source ZipInfo straight to writestr. For entries stored past ZIP64_LIMIT, that ZipInfo carries a ZIP64 extended-information field (id 0x0001) encoding the central-directory header offset, which is invalid in a local file header and yields archives that strict parsers reject (pypa#692). Remove the ZIP64 extra field from each entry before rewriting so zipfile regenerates a correct one for the new archive when needed; other extra fields are preserved.
d3a5cd0 to
2cae6e8
Compare
|
Please do not force push. What you just did undid my review process. |
|
sorry about that — that was me adding a follow-up test assertion and i amended+force-pushed out of habit, without realizing you were mid-review. won't force-push again on this PR; i'll only append commits from here so your review history stays intact. happy to squash at the end if/when you prefer. let me know how you'd like to proceed. |
|
I will squash merge as I always do when the review passes. |
|
Is this ready for review? I looked it through and I'm ready to merge, but it's marked as draft (didn't actually notice that before, sorry). |
|
Yes @agronholm, I think it's good to go, thanks. Marked ready for review |
2 participants
Fixes #692.
wheel tagsrewrites a wheel by passing each sourceZipInfostraight towritestr. For entries stored pastZIP64_LIMIT, thatZipInfocarries a ZIP64 extended-information extra field (id0x0001) holding the central-directory header offset. That field is only valid in the central directory — copied into a local file header it produces an archive that strict parsers reject (this surfaced via uv's stronger zip validation; see the pytorch/uv upstream issues linked in #692).The fix strips the ZIP64 extra field from each entry before rewriting, so
zipfileregenerates a correct one for the new archive when needed. Other extra fields are preserved.Testing
Added
test_retag_does_not_leak_zip64_into_local_headers, which forces ZIP64 on small files viaZIP64_LIMIT, retags, and asserts no local header carries a0x0001extra field. It fails onmainand passes with the fix; the full suite stays green, and the retagged archive passesZipFile.testzip().Two commits kept separate so the failing test lands first, then the fix.
disclosure: fix + test written with AI assistance; i reproduced the bug, verified fails-before/passes-after locally, and reviewed every line.