RFR 8226530: ZipFile reads wrong entry size from ZIP64 entries

[Lance Andersen]

Hi Martin,
> On Aug 7, 2019, at 2:37 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Thanks for fixing this.  Looks good.

Thank you.


> The APPNOTE.TXT spec is very confusing and surprising - it is not at all obvious why the size fields are required in the LOC ZIP64 header but not in the CEN ZIP64 header.
> I might include a reference to the sections in the PKWARE spec - 4.5.3 and 4.4.9
> It seems to be related to encryption, which the openjdk implementation does not support.
> It seems to be still required to store 0xFFFFFFFF in the regular LOC header when the ZIP64 extra field is present, so it looks to me like the LOC and CEN handling can be unified, again assuming no encryption support.

I wanted to be careful as to not tweak this code too much in one pass given its age.  So its on my todo list to spend some more time looking at this but moving in small steps to not rock the apple cart :-)

Yes, I do find APPNOTE.TXT somewhat confusing along with the references to info-zip; I really want to tread lightly while I continue to become more familiar with this code.

Hope that makes sense :-)


> 
> On Tue, Aug 6, 2019 at 1:32 PM Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> Hi 
> 
> Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8226530 <https://bugs.openjdk.java.net/browse/JDK-8226530> <https://bugs.openjdk.java.net/browse/JDK-8226530 <https://bugs.openjdk.java.net/browse/JDK-8226530>>, where ZipFile does not return the correct size from the CEN when  the Zip64 Extended Information Extra Field is used to store the entry size
> 
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html> <http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html <http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html>>
> 
> Mach5 jdk tier1-tier3 all pass
> 
> Best
> Lance
> 
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>> <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif <http://oracle.com/us/design/oracle-email-sig-198324.gif>>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>