There seems to be an error in ZIP file consistency check as implemented in _zip_checkcons . If I create zip archive that contains a large number of (relatively small) files and overall archive size is larger than 4 Gb then two archive tools I used (7z and tool built-in windows 8) will generate a zip64 file as following. Files stored at positions up to 4 Gb boundary will be marked in zip central directory with "version needed to extract" field set to 10, 20 or 21 which seems to be reasonable because they indeed can be extracted with decompression tool that knows nothing about zip64. Files stored at positions on 4 Gb boundary and up are marked with "version needed to extract" of 45.
So far so good, but now lets look at local file headers. All files stored in archive are smaller than 4 Gb so we don't need 64-bit headers locally. Hence both archive tools that I tested set "version needed to extract" field in local header for these entries at 10, 20 or 21 regardless where this data was located. This seems to be logical: you need zip64 support to find these files from central directory, but once you get to that block (i.e. by unpacking archive file-by-file without central directory) you can unpack it without knowing anything about zip64.
If archive is open with ZIP_CHECKCONS flag, _zip_checkcons will soon find this inconsistency (central directory "version to extract" field is 45, but local header version is 20) and report a broken archive if it contains any files located beyond 4 Gb boundary.
As far as I see, ZIP specifications do not require "version needed" fields to be identical in central directory and local headers. Therefore my suggestion is to change consistency check by replacing test
"(central->version_needed != local->version_needed)"
(central->version_needed >= local->version_needed)