From: Mark Wielaard

On Tue, 2003-12-09 at 20:20, Archie Cobbs wrote:
> The web site still seems to be down, so here is a bug report FWIW...
> 
>     public class xx {
>       public static void main(String[] args) throws Exception {
>           ZipFile f = new ZipFile("xx.java");
>       }
>     }
> 
> This program generates a ZipException on JDK, but Classpath
> does not try to verify the file at all so doesn't throw any
> exception... even if you then try to read the file's entries.
> 
> Instead what happens is you get null back from ZipFile.entries()
> which is not according to spec. The ZipFile constructor should try
> to do some minimal verification of the files's signature, etc.


> I think a simple fix would be to try to read the directory
> (which you are most likely going to have to do later anyway)
> in the constructor(s).


I believe that was what the code did in the past. But some programs open
lots of zip/jar files while starting up and we didn't want to read the
whole zip directory and construct all those ZipEntries during opening
when the entries might not be needed much later (or at all).

A good fix would be to only put the check that the file starts with
LOCSIG (PK0304) in the constructor, but not explicitly try to read
all entries.

************ end of email quote *************

Request verifying the ZipFile signature in the ZipFile
constructor, and throwing a ZipException if that fails.

Also, ensure that ZipFile.entries() never returns null.