RFR - 8132734: java.util.jar.* changes to support multi-release jar files

[Steve Drach]

Hi,

We’ve published another webrev for review.

Issue: https://bugs.openjdk.java.net/browse/JDK-8132734
JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305
Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ 

This one addresses the issues regarding CodeSigners, Certificates, verification, and other security issues raised in the last round, including whether third party verification is a supported use case.  I also partially fixed a nitpick involving performance while searching for versioned entries, by putting in a cache for previously searched entries.  And I found a way around the issue with windows being unable to delete jar files accessed through URL’s in one test.

Steve

> On Oct 21, 2015, at 12:54 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
>> On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
>> 
>> We might want to bring in Max to take a look if what I said is really a supported use scenario.
> 
> I haven't read Steve's latest code change. I will read if you think it's necessary.
> 
> First, I think we agree that the multi-release jar file feature is only making use of the existing jar file format and does not intend to introduce any change to its specification. This means a JarFile signed by one JDK release should be verified by another JDK release.
> 
> Ok, the next question is, should it modify the JarFile API? I hope not, because the JarFile API is the single entry we access a JarFile when we want to sign or verify it. I hope there is a brand new API for a multi-versioned jar file, probably a child class of JarFile, so that no matter you call getJarEntry() or entries() on it, you always get the versioned one and the unrelated ones are completely invisible.
> 
> If this is not OK, maybe we can rename the current JarFile to RawJarFile and name the new API JarFile. Signing and verification will work on RawJarFile.
> 
> Not sure if it's easy.
> 
> --Max

> On Oct 21, 2015, at 12:17 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi Steve,
> 
> The reifiedEntry() approach probably can help the default JarVerifier work as expected, but if I read the
> code correctly  I doubt you can get the expected CodSigner[] and Certificatte[] result from a "versioned"
> JarFileEntry, after having read all bytes from the input stream (obtained via jzf.getInputStream(JarFileEntry)),
> as the JarEntry spec suggests,. As we are passing the "reified" entry into the VerifierStream alone, without
> any reference to the original jar file entry.  It seems impossible for the original jar file entry can trace back to
> the corresponding certificates and code signers. This might be fixed by passing in the original entry together
> into the JarVerifier, but I doubt we might have a bigger issue here. I suspect with this approach an external
> verifier will have no easy way to verify the digit signature of the jar entry via java.security APIs. I would assume
> this is doable right now with current JarFile APIs, via a JarFile object, a Manifest and a target JarEntry. The external
> can get the signature via name -> manifest->attributes->signature (basically just consider to move the
> JarVerifier and couple sun.security.util classes out and use it as user code)... but with this implementation
> the name now  is the root entry, but the bytes you can read from the stream is from the versioned one.
> We might want to bring in Max to take a look if what I said is really a supported use scenario. I might be
> wrong, not a security expert :-)
> 
> Btw, for a "normal" JarEntry/ZipEntry (not a JarFileEntry), shouldn't the getInputStream(ze) simply return
> the stream for the root entry? The current implementation of getJarEntry(ze) does not seem right, as it
> returns a "versioned" JarFileEntry. I don't think you want to pass this one into VerifierStream directly,
> right? Again, I think it might be desired (at least the spec is not updated to say anything about "version")
> to simply return the input stream for the root entry.
> 
> One more "nitpick". searchForVersionedEntry() now lookups the versioned candidate via super.getEntry()
> from version to BASE_VERSION, if the version is the latest version 9, the base is 0, we are basically doing
> this search for each non-versioned-entry inside this multi-release-jar file 9 times everytime when the entry
> is asked. In worse case scenario, a multi-release-jar, with huge number of entries with a small portion are
> versioned to 9, and you are iterating it via "entries". Each lookup might be cheap, but it might be worth
> considering adding some optimization.
> 
> Best,
> Sherman