zip64 eocd not written correctly in all cases

[0-wiz-0]

The code deciding when to write a zip64 eocd has a bug:

https://github.com/madler/zlib/blob/ac8f12c97d1afd9bafa9c710f827d40a407d3266/contrib/minizip/zip.c#L1875-L1881

It only checks if there are more than 0xffff files or if the offset of the eocd is central directory ia > 0xffffffff.

However, there are cases where files that are larger than 4 GB (and thus need a zip64 extra field) are compressed to much less than 4 GB. So the offset of the central directory is below the 4GB limit, but the zip archive uses zip64 features and should have a zip64 eocd.

I agree that the PKZIP appnote is not very clear about this, but I think that sentences like:

If an archive is in ZIP64 format
and the value in this field is 0xFFFFFFFF, the size will be
in the corresponding 8 byte ZIP64 extended information 
extra field.

imply it, even though it never really defines what it means that an archive is in ZIP64 format.

[madler]

Thank you for your comment, but I disagree with your interpretation. The code is checking what it needs to check in order to emit Zip64 end records, per the appnote. I am not aware of anything in the appnote that says that if Zip64 constructs are used anywhere in the zip file, that Zip64 end records need to be present.

However in looking at the code above, I do see an error. It should be zi->number_entry >= 0xFFFF, not zi->number_entry > 0xFFFF. I'll fix that.

[tbeu]

Is it the same issue as fixed by https://github.com/zlib-ng/minizip-ng/commit/2631b7b7056ce699574ec1d6748169885530e4b8?

[madler]

@tbeu That's the commit I just made, mentioned in my comment above.