harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Gray" <chris.g...@kiffer.be>
Subject Re: Probs with checking certificates from JarInputStream
Date Tue, 12 May 2009 14:29:52 GMT
Hi Tim,

> Chris Gray wrote:
> <snip>
> > 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.?

Good question. The jar file specification is informal to say the least, but
there does seem to be some kind of consensus that for instance the
META-INF/MANIFEST.MF entry needs to come pretty darn early in the archive if
it's to be of any use - the existing Harmony code only allows META-INF/ to
precede it. It also seems reasonable to insist that the .SF and .DSA entries
have already been read in when the file to be signed is encountered (because
the signature becomes available once the file has been read fully).

OTOH I'm not so sure that all the META-INF/* entries need to be together - for
all I know it would be legal to put META-INF/INDEX.LST at the very end, for

> > I'm not a fan of long-running constructors (imagine if the jar file were
> > 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.

In fact it seems to help a lot with the jar signing if I simply add code to
JarInputStream.getNextEntry which calls read([BII) exhaustively if the current
file has the meta nature, before invoking super.getNextEntry. We want
verifier.metaEntry to be called, and this is a side-effect of read([BII); so
if the caller didn't read the file then we do it, throw away the result and
keep the side-effect. :-0

Do I need to do contributor paperwork before submitting small patches like this?



Chris Gray      /k/ Embedded Java Solutions

Scarlet says goodbye to download limits!
ADSL20 NO LIMIT, only € 29,95
Go to www.scarlet.be for more info!

View raw message