United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6575373 : Error verifying signatures of pack200 files in some cases

Details
Type:
Bug
Submit Date:
2007-06-28
Status:
Closed
Updated Date:
2013-05-24
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
deploy
OS:
linux,generic,windows
Sub-Component:
deployment_toolkit
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,6u1,6u17
Fixed Versions:

Related Reports
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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.
                                     
2010-06-11
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.
                                     
2010-04-05
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.
                                     
2010-03-12
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:
                                     
2009-12-07



Hardware and Software, Engineered to Work Together