JDK-6575373 : Error verifying signatures of pack200 files in some cases
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6,6u1,6u17
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux,windows
  • CPU: generic,x86
  • Submitted: 2007-06-28
  • Updated: 2017-05-16
  • Resolved: 2011-03-08
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.
JDK 7 Other
7 b100Fixed OpenJDK6Fixed
Related Reports
Relates :  
JDK-8015414 - Signature verification fails after pack200
Relates :  
JDK-6960415 - pack200 documentation changes
Relates :  
JDK-6969063 - (pack200) The default value of Pack200.Packer.SEGMENT_LIMIT property is empty string instead of -1
Relates :  
JDK-5078608 - Digital signatures are invalid after unpacking
Description
We are seeing a similar bug to that described in 5078608. On some machines, we get the following error when validating a large .pack.gz file (j3dcore.jar) that has been unpacked using unpack200.

jarsigner: java.lang.SecurityException: SHA1 digest error for javax/media/j3d/Alpha.class

The sequence of operations on the build machine is:

pack200 --repack
jarsigner
pack200

Then when that taget machine, which may be a different rev of the JVM, unpacks and validates it, it fails on some machines.

unpack200
jarsigner --verify

One combination that seems to break is if we repack/sign/pack on JDK 6 or 5u11 and then unpack/verify on 5u6 or 5u7.

I have put test files in the following directory:

http://download.java.net/media/java3d/bugs/pack200/

j3dcore.jar.orig       original (unsigned, not repacked)
j3dcore.jar.repacked   repacked (but unsigned) jar file
j3dcore.jar            signed jar file
j3dcore.jar.pack.gz    pack200 jar file

If you verify the j3dcore.jar file it will work on any JVM. If you unpack200 the j3dcore.jar.pack.gz file on 5u6 and then verify it, it will fail.

The workaround described in 5078608 of using "--segment-limit=-1" for both repack and pack seems to work.
Comments
SUGGESTED FIX Make segment-limit=-1 the default behavior.
11-06-2010
EVALUATION I've found the root cause of this issue. It is not related to signing process at all. The problem is that the following assumption: normalize(jar-file) == normalize(normalize(jar-file)) is not correct in common case. The customer's jar-file (unsigned_sheet_28333.jar) is a good example when this assumption does not work. The following commands: pack200.exe -r normal.jar unsigned_sheet_28333.jar pack200.exe -r normal2.jar normal.jar produce normal2.jar in which some classes (the same SheetTreeTable.class and SheetTreeTable$55.class) differ from ones in normal.jar. The first command puts 277 files from the original jar file into the first segment of the intermediate pack file, all other files go into the second segment. Then some auxiliary class attributes are removed, so the class files in the resulting normal.jar become a bit smaller. Because of this, the second command finds that these are 278 files which it is possible to put into the first segment. In result, the constants in the common constant pool of the intermediate pack file get reordered, and some class files in normal2.jar get changed. It means that the official normalization procedure doesn't work for unsigned_sheet_28333.jar, so the procedure is not fully correct. I see two resolution options here: 1) Modify the official procedure - add an extra "pack200 ���-repack" call 2) Modify the implementation of "pack200 ���-repack" - programmatically do it two times.
05-04-2010
EVALUATION 1) The following two commands: pack200.exe -g temp.pack sheet_27485.jar unpack200.exe temp.pack new.jar produce new.jar that has two class files different from ones in sheet_27485.jar. These are: com/adaptiveplanning/ui/desktop/sheet/SheetTreeTable.class com/adaptiveplanning/ui/desktop/sheet/SheetTreeTable$55.class The difference appeared because the constants in their constant pools were reordered by some reason, and the references to these constants were correspondingly changed too. 2) The following repack command: pack200.exe -r r.jar sheet_27485.jar produces r.jar with the class files that are different from the original ones in exactly the same way (the contents of new.jar and r.jar are identical). At least, this looks consistent to me. These experiments show that sheet_27485.jar is not normalized. Now we need to understand why it is not normalized. The customer confirmed that they follow the official procedure for jar file normalization. We asked for the link to the original jar file *before* it was normalized to understand how it differs from sheet_27485.jar.
12-03-2010
EVALUATION This seems to be another corner case of 5078608, need to see why exactly that one file changed after signing, a prime suspect is an anonymous class or an inner class. Nevertheless, we need to modify the deployment guide and spell out the remedies in the deployment guide see the comment section:
07-12-2009