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

[David M. Lloyd]

FWIW I agree - it's just weird to have the behavior change after the 
fact like that.

On 10/26/2015 11:37 PM, Xueming Shen wrote:
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.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


--
- DML