List Archive

Thread

Thread Index

Message

From: Martin Buchholz <martinrb%google.com@localhost>
To: "Jay Freeman (saurik)" <saurik%saurik.com@localhost>
Subject: Re: [PATCH 0/3] libzip does not use EOCD nentry field in PK-WARE compatible way
Date: Tue, 16 Aug 2016 08:46:04 -0700

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.

Made by MHonArc.