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.w...@oracle.com> wrote: > >> On Oct 21, 2015, at 3:17 PM, Xueming Shen <xueming.s...@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.s...@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
