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 [*].
JarFile:
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(
getManifestFromReference(),
ze instanceof JarFileEntry ?
(JarEntry) ze : getJarEntry(ze.getName()),
super.getInputStream(ze),
jv);
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 }
MultiReleaseJarURLConnection
—
Given your changes above i am confused how your test passes for instances of URLJarFileEntry since they cannot be reified.
Paul.
[*] AFAICT JarVerifier directly accesses the fields JarEntry.signers/certs.
More information about the core-libs-dev
mailing list