we have some customers who have reported problems after the update to Oracle Sun JRE 1.8.0_141.
The JWS is failing with the following error;
java.lang.SecurityException: digest missing for com/ibm/ps/uil
at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
at java.util.jar.JarVerifier.processEntry(Unknown Source)
at java.util.jar.JarVerifier.update(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
com.sun.deploy.net.JARSigningException: Could not verify signing in resource: http://FTOHubA:15200/classes/cnp_ps.jar
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
This issue is related due a known bug in this Oracle Sun JRE built 141 and not with a certain ITM jar file.
Oracle has provided a fixed built Oracle Sun JRE 1.8.0_144.
From the Oracle Sun JRE 1.8.0_144 release node:
java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry
The java.util.zip.ZipEntry API doc specifies "A directory entry is defined to be one whose name ends with a /". However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when
- the passed in argument entryName does not end with a /, and
- there is a matching zip directory entry with name entryName + / in the zip file.
With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.
To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to "false".
This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs that has caused some WebStart applications to fail to load.
Please update your JRE to Oracle Sun JRE 1.8.0_144 and your JWS will work again.
Subscribe and follow us for all the latest information directly on your social feeds: