Bug ID: JDK-6543940 Exception thrown when signing a jarfile in java 1.5

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other	JDK 6	JDK 7
5.0u14 b01Fixed	6u18Fixed	7Fixed

The ISV is getting the exception when signing their jar files (attached). 
It can be duplicated on both Windows and Solaris SPARC.

java version "1.5.0_10"

1. created a keystore in Java 1.5.
keytool -genkey -alias jim -keystore jimstore

2. sign the Test_InstallLogUtil.jar
jarsigner -keystore jimstore -signedjar sTest_InstallLogUtil.jar
Test_InstallLogUtil.jar jim

3. update the signed jar file
jar -uvf sTest_InstallLogUtil.jar Main.jar

4. sign the updated jar file again
jarsigner -keystore jimstore -signedjar ssTest_InstallLogUtil.jar
sTest_InstallLogUtil.jar jim

5. verify the newer signed jarfile
jarsigner -verify -verbose -keystore jimstore ssTest_InstallLogUtil.jar

jarsigner: java.lang.SecurityException: Invalid signature file digest
for Manifest main attributes

EVALUATION We can use the raw bytes of the old header if the content is not changed. By "not changed", it means Attributes objects equals() to each other. Note there're 2 reasons that the raw bytes will change when the content is not changed: 1. Undetermined order of keys in a Map 2. The continuation of a long key-value pair into multiple lines.
21-06-2007
EVALUATION Why must the customer insert new classes into the original jar? Why can't they put their own classes into another jar file, sign it and release it along with the original jar? It's always not a good practice to alter an existing signed jar. The signature does not only protect the binary classes, but other meta information that's recorded in META-INF/MANIFEST.MF. Although in this exact case, we may be able to change some codes to make the old signature valid, there's no "fix" to cover all kinds of similar issues. There are quite some chances that the meta information be changed during content updating and/or re-signing processes, and in these cases, the verifying on the old signature MUST fail.
24-04-2007
EVALUATION During the re-signing process, the order of the headers in MANIFEST.MF is changed (they are stored inside a normal HashMap thus the insert order cannot be preserved), so the hash value of it is changed and the old signature goes invalid.
23-04-2007
WORK AROUND In the case of this bug, the original Test_InstallLogUtil.jar is signed by a certificate whose alias is ALIAS1. After the re-signing, the manifest file got changed and the old signature goes invalid. Before any real fix to the bug, the customer may choose either: 1. Re-sign the jar with ALIAS1 if customer still has the key 2. If the check for ALIAS1 is not necessary, remove the signature of ALIAS1 from the jar before or after the signing, possibly by running zip -d filename.jar META-INF/ALIAS1.SF META-INF/ALIAS1.DSA However, if the customer has no key for ALIAS1 but still want the signature inside the jar file for checking, no workaround is available.
11-04-2007
EVALUATION Confirmed, investigating now.
10-04-2007

Relates :	JDK-2179108 - jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13
Relates :	JDK-2179109 - jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13
Relates :	JDK-6712755 - jarsigner fails to sign itextasian.jar since 1.5.0_b14, it works with 1.5.0_13
Relates :	JDK-6948909 - Jarsigner removes MANIFEST.MF info for badly packages jar's