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

Xueming Shen xueming.shen at oracle.com
Tue Oct 27 04:37:35 UTC 2015

Hi Steve,

I know I stared to sound like a broken record :-) But I would like to suggest the team one more time to reconsider the current decision of using the "set" methods to change the configuration setting/status of an existing JarFile to enable the multi-version support.

public JarFile setVersioned(int version); public JarFile setRuntimeVersioned();

The main concern here is the current approach basically transfers the JarFile from a read-only/ immutable object with consistent behavior (to entry inquiry) to a mutable container of entries with possibility of inconsistent behavior. The newly introduced setVersioned/setRuntimeVersioned really have no way to guarantee A expected result from the updated version-enabled getEntry() method, as someone else might set an unexpected different "version" between your setting and getting, or even worse, in the middle of your entries() invocation, for example, in which you get part of your entries to version N and the rest to version M.

So It might be desired to have the "versioned support" enabled in the constructor, so once you get that version enabled JarFile, it stays that way for its lifetime with consistent result for the entry inquiry, as the current API does.

I do realize that there might be use case that the getEntry invoker might not have the access to the creation of the corresponding jar file (such as the use scenario in that JarURLConnection?), so you can't create a version-enabled JarFile at the very beginning via the constructor. But doesn't this also make my concern more real. If you don't have the control of the lifetime of that JarFile, you don't really have the control of who is setting or going to set the version of that mutable JarFile, right?

An alternative might be to have change the setVersioned/setRuntimeVersioned() to

public jarFile getVersioned(int version); public jarFile getRuntimeVersioned();

to return a new copy of the existing JarFile with the desired verisoning support. Yes, it might be too heavy from performance perspective :-) and we might have to do some tricky stuff (it would be easier if ZipJarFile is interface ...) to have a light wrapper class to delegate everything to the real one.

That said, I'm fine to be told "the pros and cons were considered, and this is the best for the supported use scenario":-) In that case, it might deserve some wording in the spec notes to prepare the developer the possible unexpected.

Thanks, Sherman

On 10/26/15 10:26 AM, Steve Drach wrote:

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