8132734: java.util.jar.* changes to support multi-release jar files (original) (raw)

Steve Drach steve.drach at oracle.com
Mon Oct 26 17:26:29 UTC 2015

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 BASEVERSION, 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

More information about the core-libs-dev mailing list