Could not verify signing in patched jar

Question

I have encountered a strange bug in JWS verification of the signing of a resource updated via a jardiff patch.
We have a jar resource where the only change is the contents of a text file, and when the webstart client downloads the patch created by the jnlp-servlet, it reports:
Could not verify signing in resource: (http://oas-psolis-test.health.wa.gov.au:9002/PSOLIS-SwingApp-TES/PSOLIS-GUI-graphics.jar, 1.2)
The wrapped exception is:
java.lang.SecurityException: SHA1 digest error for Themes/DESERT.properties
at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:191)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:207)
at java.util.jar.JarVerifier.update(JarVerifier.java:194)
at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:380)
at com.sun.javaws.security.SigningInfo.checkSigning(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
at com.sun.javaws.Launcher.downloadResources(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Thread.java:536)
v1.2 is the new version of the jar in question (PSOLIS-GUI-graphics.jar). DESERT.properties is NOT the changed text file, but rather another text file which has not changed (ie: being used from the v1.1 previously downloaded).
The patch jar contains an essentially empty index.jd file, with just the line:
version 1.0
As you can tell from the above, no resources have been renamed, just one text/properties file has different contents (so this is not immediately obviously <http://developer.java.sun.com/developer/bugParade/bugs/4474211.html> - but regarding 4474211, how does one enable the -nonminimal switch to jardiff from the JNLP servlet?).
Nor is it obvious that this is an instance of bug 4739089 <http://developer.java.sun.com/developer/bugParade/bugs/4739089.html>
As you would expect, the patch jar file also contains the modified text file, plus the manifest.mf and the signing data files.
If I delete the webstart cache first the application downloads and runs fine (which proves there is nothing wrong with the signing in this jar). Another workaround is not to include the base/old version (v1.1) of the jar in the war.
Both these workarounds are impractical - I can't get all the users to delete their webstart caches on each new version (of which we have many (both users and version releases)), and my build/deploy process automatically creates versioned jars (based on whether any source files have changed), I would need to modify my process to never provide diffs for this very large jar (and perhaps, any of my jars?), and hence lose jardiffing benefits altogether (I just spent a long time developing this build process to automate versioned jars for webstart!)
These jar files are never altered once created, and the signing is the last stage of creating the jar files (though as I mentioned above, that the signatures are fine is demonstrated by both workarounds, it is only the patching which causes the issue).
We have reproduced this problem using both JWS v1.4.1 clients and JWS v1.0.1 (from JRE v1.4.0) client - our users use the latter as they require support for Windows 95, sigh.
While I have a copy of a v1.4.1 cache in a state from which I can reproduce the error, I haven't managed to get a case where I can clear the cache, deploy version A, download it, deploy version B and download it to reproduce the error. This means that I haven't got a process to setup a test of v1.4.2_02 of JWS.
I am using the jnlp-servlet.jar from the "JNLP Developers Pack v1.2 FCS".
Has anyone else encountered a similar problem, or know of a solution (which works with the 1.0.1 JWS client for long suffering 95 users)?
An interesting side-note for OC4J standalone users - when oc4j expands the EAR (and its component WAR files) under the j2ee/home/applications directory, it does not clear out the old contents from any previous deployment of the same application (name) - I modified my deploy to not include previous jar versions, and yet the client was still patching - because the old jar file versions were left there by oc4j, joy!

Answer 1

Even I am facing a similar kind of problem. When webstart is downloading JRE_1.4.2_02.jar, I am getting the following error the very time itself.
java.lang.SecurityException: SHA1 digest error for jre.jar
     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.read(Unknown Source)
     at com.sun.javaws.security.SigningInfo.checkSigning(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
     at com.sun.javaws.Launcher.downloadResources(Unknown Source)
     at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
     at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
JRE_1.4.2_02.jar is a signed and verified jar that contains jre.jar. This is being downloaded on to the client for the first time. Webstart version used is 1.0.1. Can any tell me what may be the problem?