Latest Java 8.141 update breaks my web app

[sderrick]

I had a user upgrade her system to 8.141. Now when loading our editor(SDK) she gets the following error.

com.sun.deploy.net.JARSigningException: Could not verify signing in resource: https://www.mbepapers.org/editor1/lib/o ... .1.0.4.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)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Running the editor on 8.131 was fine. I upgraded one of my laptops to 8.141 and now have the same problem?

Any ideas?

thanks,

Scott

[sderrick]

just found this. since this is your jar not sure what to do?

Known Issues

deploy/webstart
JAR file validation changes

After upgrading to the JDK July CPU release (8u141/7u151/6u161), when executing Java Webstart applications, customers may encounter an exception like
“java.lang.SecurityException: digest missing for …” that prevents the application from loading.

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:

NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.

1. Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
2. Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
3. Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
4. Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).

NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

5. Re-sign the JAR file.

[Radu]

Hi Scott,

Another one of our customers using the Java applet reported the same problem and workaround on Friday.
This particular JAR library is a third-party library we need in order to have XML catalogs work with the applet.
You should try to automate making those changes you described to the JAR on your side before signing all the applet's JAR libraries.
On our side we can try to also make the same changes and distribute the JAR library with the corrected path in a future version of the SDK.

Regards,
Radu

[sderrick]

Is this the only jar that needs the name fixed?

[Radu]

Hi,

From what I know from our other end users who reported this, the oxygen-resolver.jar is the only JAR with the problem.

Regards,
Radu