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 example. > > 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. 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? Regards Chris 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!
