Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6575373

Error verifying signatures of pack200 files in some cases

    Details

    • Subcomponent:
    • Resolved In Build:
      b100
    • CPU:
      generic, x86
    • OS:
      generic, linux, windows
    • Verification:
      Verified

      Backports

        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.

          Issue Links

            Activity

            Hide
            ksrini Kumar Srinivasan added a comment -
            BT2: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:
            Show
            ksrini Kumar Srinivasan added a comment - BT2: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:
            Hide
            nikgor Nikolay Gorshkov added a comment -
            BT2: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.
            Show
            nikgor Nikolay Gorshkov added a comment - BT2: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.
            Hide
            nikgor Nikolay Gorshkov added a comment -
            BT2: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.
            Show
            nikgor Nikolay Gorshkov added a comment - BT2: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.
            Hide
            nikgor Nikolay Gorshkov added a comment -
            BT2:SUGGESTED FIX

            Make segment-limit=-1 the default behavior.
            Show
            nikgor Nikolay Gorshkov added a comment - BT2:SUGGESTED FIX Make segment-limit=-1 the default behavior.

              People

              • Assignee:
                ksrini Kumar Srinivasan
                Reporter:
                kcr Kevin Rushforth
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: