JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"
claes.redestad at oracle.com
Fri Jan 20 00:11:07 UTC 2017
On 2017-01-20 00:35, Xueming Shen wrote:
> Thanks Claes!
> webrev has been updated accordingly
> 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.
>> On 2017-01-19 22:39, Xueming Shen wrote:
>>> 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
>>> 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
>>> in a binary zip/jar file (which is not encouraged for jdk repo) for the
>>> regression test.
More information about the nio-dev