RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

Paul Sandoz paul.sandoz at oracle.com
Thu Mar 3 11:26:51 UTC 2016

> On 2 Mar 2016, at 20:12, Steve Drach <steve.drach at oracle.com> wrote:
> Please review the following fix for JDK-8150679
> webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ <http://cr.openjdk.java.net/~sdrach/8150679/webrev/>
> issue: https://bugs.openjdk.java.net/browse/JDK-8150679 <https://bugs.openjdk.java.net/browse/JDK-8150679>
> The test was modified to demonstrate the problem.

You are essentially bombing out of MR-JAR functionality if the JarEntry is not an instance of JarFileEntry. That might be ok for a short-term solution, but it might require some further deeper investigation on things that extend JarEntry and how it is is used by VerifierStream [*].


 895     private JarEntry verifiableEntry(ZipEntry ze) {
 896         if (ze == null) return null;

You don’t need this. The code will anyway throw an NPE elsewhere, and the original code threw an NPE when obtaining the name:

        return new JarVerifier.VerifierStream(
            ze instanceof JarFileEntry ?
            (JarEntry) ze : getJarEntry(ze.getName()),

 897         if (ze instanceof JarFileEntry) {
 898             // assure the name and entry match for verification
 899             return ((JarFileEntry)ze).reifiedEntry();
 900         }
 901         ze = getJarEntry(ze.getName());
 902         assert ze instanceof JarEntry;

This assertion is redundant as the method signature of getJarEntry returns JarEntry.

 903         if (ze instanceof JarFileEntry) {
 904             return ((JarFileEntry)ze).reifiedEntry();
 905         }
 906         return (JarEntry)ze;
 907     }


Given your changes above i am confused how your test passes for instances of URLJarFileEntry since they cannot be reified.


[*] AFAICT JarVerifier directly accesses the fields JarEntry.signers/certs.

More information about the core-libs-dev mailing list