Zip64 Extra Header is not parsed conditionally #457

Closed
opened 2026-01-29 22:12:24 +00:00 by claunia · 1 comment
Owner

Originally created by @DannyBoyk on GitHub (Apr 26, 2021).

The current logic for the Zip64 extra header assumes that certain fields are present by the number of bytes in the extra header, but the specification indicates that the fields that are being parsed are based on the values in the local entry header, namely that the fields in the extra header correspond to those fields in the local header that are set to uint.MaxValue (or ushort.MaxValue for the disk number).

We have encountered Zip64 files in our production systems that only specify a compressed size in their Zip64 extra fields and SharpCompress assumes these represent the uncompressed size since only one value is specified.

Originally created by @DannyBoyk on GitHub (Apr 26, 2021). The current logic for the Zip64 extra header assumes that certain fields are present by the number of bytes in the extra header, but the specification indicates that the fields that are being parsed are based on the values in the local entry header, namely that the fields in the extra header correspond to those fields in the local header that are set to uint.MaxValue (or ushort.MaxValue for the disk number). We have encountered Zip64 files in our production systems that only specify a compressed size in their Zip64 extra fields and SharpCompress assumes these represent the uncompressed size since only one value is specified.
Author
Owner

@adamhathcock commented on GitHub (Jun 4, 2021):

Released https://www.nuget.org/packages/SharpCompress/0.28.3

@adamhathcock commented on GitHub (Jun 4, 2021): Released https://www.nuget.org/packages/SharpCompress/0.28.3
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#457