> On 15 Oct 2015, at 11:08 p.m., Claes Redestad <claes.redes...@oracle.com> > wrote: > > > On 2015-10-15 23:21, Chris Hegarty wrote: >>> On 15 Oct 2015, at 21:59, e...@zusammenkunft.net wrote: >>> >>> Hello, >>> >>> This does change a bit the semantic of the length check. If the stream >>> would return more bytes than the zipentry says the new version would ignore >>> them, the old version was consuming then and then fail the check. However >>> I am not sure if this is relevant. >> Right, there are certainly some subtle differences resulting from >> the proposed change. When working on JDK-8138978 I thought >> about using readNBytes, but played it safe as IOUtils was growing >> the bye[] lazily too, so no real perf difference. In fact, I think I seen >> a test failure with using readNBytes here. I’ll have to check. > > Seeing no jtreg test failures in java/util/zip nor java/util/jar (apart from > 2 ignored tests), but I can see a reason for the current implementation being > conservative: Corrupt/malicious jar files might lie about the entry length > and report very large values, which could bring a down with OOME. > > I believe we could be both safe and faster than baseline by adding a > reasonable limit for when to use readNBytes, e.g., 32k would deal with the > majority of .class files.
Sounds good to me. -Chris. > /Claes
