JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

[Claes Redestad]

On 2017-01-20 00:35, Xueming Shen wrote:
> Thanks Claes!
>
> webrev has been updated accordingly
>
> http://cr.openjdk.java.net/~sherman/8173072/webrev

+1

/Claes

>
> On 01/19/2017 03:04 PM, Claes Redestad wrote:
>> Looks good to me.
>>
>> You could simplify a bit and write: int end = locPos + locSZ - 4;
>> and use direct comparisons instead of adding 4 in each test.
>>
>> Thanks!
>>
>> /Claes
>>
>> On 2017-01-19 22:39, Xueming Shen wrote:
>>> Hi
>>>
>>> Please review the change for
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173072
>>> webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
>>>
>>>
>>> As described in the issue, the root cause is that the offending zip/jar
>>> file
>>> has a "extended timestamp extra field" that does not strictly follow the
>>> spec, AND the zipfs implementation does not do a good job to do sanity
>>> check on the data size like what the ZipEntry code does when check the
>>> timestamps. The change here is to check both the flag and the length,
>>> stop reading a/ctime if there is no more data, even the flags field says
>>> there are more data.
>>>
>>> I have run the test manually to verify the change, but decided not to
>>> check
>>> in a binary zip/jar file (which is not encouraged for jdk repo) for the
>>> regression test.
>>>
>>> Thanks,
>>> Sherman
>