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

Mixed code dialog running CACHED applet that reads classloader manifest resource

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Duplicate
    • Affects Version/s: 7u45
    • Fix Version/s: None
    • Component/s: deploy
    • Labels:
    • Subcomponent:
    • OS:
      windows_7

      Description

      FULL PRODUCT VERSION :
      Java console:
      Java Plug-in 10.45.2.18
      Using JRE version 1.7.0_45-b18 Java HotSpot(TM) Client VM

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 6.1.7601]

      A DESCRIPTION OF THE PROBLEM :
      When running a signed, privileged applet from a single CACHED .jar file, and the applet reads the applet classloader manifest resources, it receives a dialog: Security Warning, Block

      potentially unsafe components from being run? Java has discovered application components that could indicate a security concern.... Block / Don't Block .... The application contains both

      signed and unsigned code.

      There is only one applet .jar file, so there is no unsigned code. The warning is displayed only when .jar file caching is enabled in Java Control Panel. It does not matter if the .jar file

      was previously cached or not.

      This bug seems similar to https://bugs.openjdk.java.net/browse/JDK-8026757 , except that this is an applet situation and only occurs when .jar file caching is enabled.

      REGRESSION. Last worked in version 7u40

      ADDITIONAL REGRESSION INFORMATION:
      java -version
      java version "1.7.0_45"
      Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
      Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      Enable .jar file caching in the Java Control Panel.
      Compile, sign with all-permissions, and run the test applet given below.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Applet runs without warnings.
      Applet prints the manifest URLs from the classloader into the Java Console.
      ACTUAL -
      When running a signed, privileged applet from a single CACHED .jar file, and the applet reads the applet classloader manifest resources, it receives a dialog: Security Warning, Block potentially unsafe components from being run? Java has discovered application components that could indicate a security concern.... Block / Don't Block .... The application contains both signed and unsigned code.

      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      When running a signed, privileged applet from a single CACHED .jar file, and the applet reads the applet classloader manifest resources, it receives a dialog: Security Warning, Block potentially unsafe components from being run? Java has discovered application components that could indicate a security concern.... Block / Don't Block .... The application contains both signed and unsigned code.

      Stack trace at the time the Security Warning dialog is displayed:
      "AWT-EventQueue-2" prio=4 tid=0x0721f000 nid=0x1120 runnable [0x0869d000]
         java.lang.Thread.State: RUNNABLE
      at com.sun.deploy.uitoolkit.ui.NativeMixedCodeDialog._show(Native Method)
      at com.sun.deploy.uitoolkit.ui.NativeMixedCodeDialog.access$000(Unknown Source)
      at com.sun.deploy.uitoolkit.ui.NativeMixedCodeDialog$2.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at com.sun.deploy.uitoolkit.ui.NativeMixedCodeDialog.showImmediately(Unknown Source)
      at com.sun.deploy.uitoolkit.ui.NativeMixedCodeDialog.show(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler.showMixedTrustDialog(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler.access$1100(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler$ParentCallback.checkAllowed(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
      - locked <0x29d48948> (a com.sun.deploy.security.CPCallbackHandler$ParentCallback)
      at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1700(Unknown Source)
      at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$JarLoader.findResource(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$1.next(Unknown Source)
      at com.sun.deploy.security.DeployURLClassPath$1.hasMoreElements(Unknown Source)
      at java.net.URLClassLoader$3$1.run(Unknown Source)
      at java.net.URLClassLoader$3$1.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader$3.next(Unknown Source)
      at java.net.URLClassLoader$3.hasMoreElements(Unknown Source)
      at sun.misc.CompoundEnumeration.next(Unknown Source)
      at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source)
      at hwc.hwc.<init>(hwc.java:25)

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      package hwc;

      import java.applet.*;
      import java.io.IOException;
      import java.net.URL;
      import java.util.Enumeration;
      import java.util.jar.JarFile;

      public class hwc extends Applet
      {
         public hwc()
         {
            super();
            System.out.println("HWC : in constructor");
            System.out.println("HWC : Classloader: " + getClass().getClassLoader().toString());

            // Loop through the manifests of all the .jar files, with the intent of
            // finding our own and verifying something in them.
            Enumeration jarfileManifestURLs = null;
            try
            {
               System.out.println("Point A");
               jarfileManifestURLs = Thread.currentThread().getContextClassLoader().getResources(JarFile.MANIFEST_NAME);
               System.out.println("Point B");
               while (jarfileManifestURLs.hasMoreElements())
               {
                  System.out.println("Point C");
                  URL jarfileManifestURL = (URL)jarfileManifestURLs.nextElement();
                  System.out.println("Point D");
                  System.out.println("Manifest URL: " + jarfileManifestURL.toString());
                  System.out.println("Point E");
               }
            }
            catch (IOException e1)
            {
               throw new RuntimeException(e1);
            }
         }
      }
      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      None known.
      Turning off .jar file caching is not practical for all of our customers (I represent an ISV.)
      Use of Trusted-Library is not allowed as our use of javascript requires us to sign with Caller-Allowable-Codebase instead.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dcherepanov Dmitry Cherepanov
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: