JDK-5078608 : Digital signatures are invalid after unpacking
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 5.0,6u17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows
  • CPU: generic,x86
  • Submitted: 2004-07-27
  • Updated: 2013-05-24
  • Resolved: 2004-09-01
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
5.0u1 01Fixed 6Fixed
Related Reports
Relates :  
Relates :  
Relates :  
The procedure to pack and signing a jar is broken. Specifically if the jar
is a large one. One will get an error as
jarsigner -verify ./out/foo.jar 
jarsigner: java.lang.SecurityException: SHA1 digest error for original/org/jfree/chart/axis/Axis.class

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.5.0_01 mustang FIXED IN: 1.5.0_01 mustang INTEGRATED IN: 1.5.0_01 mustang

WORK AROUND There are two workarounds for this issue: 1. use --segment-limit=-1 during repack and packing. OR 2. i) pack200 --repack b.jar a.jar ii) sign b.jar iii) pack200 --repack c.jar b.jar iv) sign c.jar v) pack200 out.jar.pack.gz c.jar Now: out.jar.pack.gz can be deployed.

SUGGESTED FIX The fix is simple, I think. Adjust the segment-limit heuristic to count only *.class files in the size estimate. Non-class files, such as the signature container, can therefore change size without affecting the segmentation. This is a reasonable change to the heuristic, because non-class files do not require significant unpacker resources (they are appended to the segment, not integrated within it). ###@###.### 2004-07-27

EVALUATION The procedure to pack and sign a file is to use pack200 --repack ....... sign the normalized jar and the pack it again. The problem is that when the jar is signed the jarsigner adds a signature digest into the meta-inf, this will cause the packer to re-order the segmenting. The re-ordering of the segments may cause a re-ordered per-segment constant pool. Therefore the references to the cp entries will be different. This will invalidate the digital hash. ###@###.### 2004-07-26 Fixed and release in J2SE 5.0 Update1 ###@###.### 2004-12-21 00:59:14 GMT