You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gh-103861: Fix Zip64 extensions not being properly applied in some cases (#103863)
Fix Zip64 extensions not being properly applied in some cases:
Fixes an issue where adding a small file to a `ZipFile`
object while forcing zip64 extensions causes an extra Zip64 record to be
added to the zip, but doesn't update the `min_version` or file sizes in
the primary central directory header.
Also fixed an edge case in checking if zip64 extensions are required:
This fixes an issue where if data requiring zip64 extensions was added
to an unseekable stream without specifying `force_zip64=True`, zip64
extensions would not be used and a RuntimeError would not be raised when
closing the file (even though the size would be known at that point).
This would result in successfully writing corrupt zip files.
Deciding if zip64 extensions are required outside of the `FileHeader`
function means that both `FileHeader` and `_ZipWriteFile` will always be
in sync. Previously, the `FileHeader` function could enable zip64
extensions without propagating that decision to the `_ZipWriteFile`
class, which would then not correctly write the data descriptor record
or check for errors on close.
If anyone is actually using `ZipInfo.FileHeader` as a public API without
explicitly passing True or False in for zip64, their own code may still be
susceptible to that kind of bug unless they make a similar change to
where the zip64 decision happens.
Fixes#103861
---------
Co-authored-by: Gregory P. Smith <[email protected]>
"""Test that forcing zip64 extensions correctly notes this in the zip file"""
1085
+
1086
+
# GH-103861 describes an issue where forcing a small file to use zip64
1087
+
# extensions would add a zip64 extra record, but not change the data
1088
+
# sizes to 0xFFFFFFFF to indicate to the extractor that the zip64
1089
+
# record should be read. Additionally, it would not set the required
1090
+
# version to indicate that zip64 extensions are required to extract it.
1091
+
# This test replicates the situation and reads the raw data to specifically ensure:
1092
+
# - The required extract version is always >= ZIP64_VERSION
1093
+
# - The compressed and uncompressed size in the file headers are both
1094
+
# 0xFFFFFFFF (ie. point to zip64 record)
1095
+
# - The zip64 record is provided and has the correct sizes in it
1096
+
# Other aspects of the zip are checked as well, but verifying the above is the main goal.
1097
+
# Because this is hard to verify by parsing the data as a zip, the raw
1098
+
# bytes are checked to ensure that they line up with the zip spec.
1099
+
# The spec for this can be found at: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
"""Test that creating a zip without seeking will use zip64 extensions if the file size is provided up-front"""
1162
+
1163
+
# This test ensures that the zip will use a zip64 data descriptor (same
1164
+
# as a regular data descriptor except the sizes are 8 bytes instead of
1165
+
# 4) record to communicate the size of a file if the zip is being
1166
+
# written to an unseekable stream.
1167
+
# Because this sort of thing is hard to verify by parsing the data back
1168
+
# in as a zip, this test looks at the raw bytes created to ensure that
1169
+
# the correct data has been generated.
1170
+
# The spec for this can be found at: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
0 commit comments