Re: [PATCH 0/3] libzip does not use EOCD nentry field in PK-WARE compatible way

[Martin Buchholz <martinrb%google.com@localhost>]

I'm not looking at any of the libzip code, but I agree with Jay's strategy.

On Tue, Aug 16, 2016 at 1:54 AM, Jay Freeman (saurik) <saurik%saurik.com@localhost> wrote:

As described in my previous e-mail, I'm trying to work with zip files that
are generated by Apple for use with their OTA update mechanism, which have
more than 65k files but are stored using the 16-bit file format. These are
fully supported by PK-WARE's unzip utility, *on purpose, not on accident*.

I worked on the JDK's zip implementation - here's a comment I wrote many years ago:

    /* Initialize zip file data structures based on the total number

     * of central directory entries as stored in ENDTOT.  Since this

     * is a 2-byte field, but we (and other zip implementations)

     * support approx. 2**31 entries, we do not trust ENDTOT, but

     * treat it only as a strong hint. 

There's also the other common bug of seeing that ENDTOT is 0xFFFF and assuming that means ZIP64 is surely being used.