harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Probs with checking certificates from JarInputStream
Date Tue, 12 May 2009 12:47:23 GMT
Chris Gray wrote:
> Note that this code doesn't even call closeEntry() on the meta-files it 
> encounters, and yet it still works on RI 1.4/1.6. On harmony the *.DSA and 
> *.SF files are simply skipped, without any entries being added to the 
> metaEntries map. Adding an else clause in which meta-files are first 
> exhaustively read([BII) and then closeEntry() is called seems to help a lot.

A shortcoming of Harmony for sure.

> I think the answer is to treat all meta-files the way we now treat the 
> manifest, i.e. provided they are presented in the "right" order we read them 
> all in during the JarInputFile constructor and extract whatever data will 
> later be needed by the JarVerifier. "Right" order means something like: meta-
> files precede all non-meta files, manifest precedes all except possible the 
> META-INF/ directory itself. This implies that we also suck in the META-
> INF/INDEX.LST file and omy[deity] the META-INF/services directory if present, 
> unless we can insist that these come after the signature data. Instead of 
> mEntry we would have a whole queue of entries buffered and waiting for 
> getNextEntry() to fish them out.

Eek.  Is this based on any reading of the spec, or experimentation, or
just your hunch about the order in which these things should be
considered?  Apart from the fact that there are numerous places we
should be looking, what happens when there are differences of opinion
between them, etc.?

> I'm not a fan of long-running constructors (imagine if the jar file were being 
> read in from a slow server over a chunked HTTP stream - been there, done 
> that), but in this case it's probably justified; arguably the JarInputStream 
> object is not fully constructed until the signatures have been processed.

Yeah, though there are any number of misbehaving data streams that could
cause such delays in the JarInputStream construction today that I think
we are already in that game.

> What a mess. What a format. What an API.



View raw message