-
Bug
-
Resolution: Fixed
-
P3
-
6u19
FULL PRODUCT VERSION :
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]
A DESCRIPTION OF THE PROBLEM :
We had this main.jnlp file:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
codebase="http://localhost:8080"
href="test.jnlp">
<information>
<title>Servoy Client - servoy_client</title>
<vendor>Servoy</vendor>
<homepage href="http://www.servoy.com/"/>
<description>Database client</description>
<icon href="/lib/images/servoy_client_icon.gif" />
<icon kind="splash" href="/lib/splashclient.gif" width="64" height="64"/>
</information>
<resources>
<j2se version="1.5+" />
<j2se version="1.6+" />
<jar href="main.jar" download="eager" version="8"/>
<extension name="utility" href="utility.jnlp"/>
</resources>
<application-desc main-class="com.first.jar.Main">
</application-desc>
<security>
<all-permissions/>
</security>
</jnlp>
then in the extention jnlp:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
codebase="http://localhost:8080"
href="utility.jnlp">
<information>
<title>Servoy Client - servoy_client</title>
<vendor>Servoy</vendor>
<homepage href="http://www.servoy.com/"/>
<description>Database client</description>
</information>
<resources>
<jar href="utility.jar" download="eager" version="8"/>
<jar href="utility2.jar" download="eager" version="2"/>
</resources>
<component-desc/>
</jnlp>
we dont specify the security,
Before update 19 of java 6 this was not a problem, even the 2 utility classes didnt need to be signed. But now we somehow have to sign it.
But even if we sign the 2 jars now. We still have to also add
<security>
<all-permissions/>
</security>
to all our extention jars.
This update 19 breaks so many things for our product this way.
One thing is that we have a product that can be extended by plugins. So those extensions are not provided by us but by 3th party plugin developers. Now all those developers need to sign there code and make sure that all there jnlp files will generate that security tag also, even if they dont need anything os specific.. Why is the security not inherited from the main jnlp file?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
try the above jnlp files including the use of extentions.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
I get a message that signed and unsiged code is being tried to run (which is not true! and when press yes in that dialog that i want to block it i get this:
ava.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost:8080/utility.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(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.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.first.jar.Main.main(Main.java:12)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
REPRODUCIBILITY :
This bug can be reproduced always.
SUPPORT :
YES
Release Regression From : 6u19
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
java version "1.6.0_19"
Java(TM) SE Runtime Environment (build 1.6.0_19-b04)
Java HotSpot(TM) 64-Bit Server VM (build 16.2-b04, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]
A DESCRIPTION OF THE PROBLEM :
We had this main.jnlp file:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
codebase="http://localhost:8080"
href="test.jnlp">
<information>
<title>Servoy Client - servoy_client</title>
<vendor>Servoy</vendor>
<homepage href="http://www.servoy.com/"/>
<description>Database client</description>
<icon href="/lib/images/servoy_client_icon.gif" />
<icon kind="splash" href="/lib/splashclient.gif" width="64" height="64"/>
</information>
<resources>
<j2se version="1.5+" />
<j2se version="1.6+" />
<jar href="main.jar" download="eager" version="8"/>
<extension name="utility" href="utility.jnlp"/>
</resources>
<application-desc main-class="com.first.jar.Main">
</application-desc>
<security>
<all-permissions/>
</security>
</jnlp>
then in the extention jnlp:
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+"
codebase="http://localhost:8080"
href="utility.jnlp">
<information>
<title>Servoy Client - servoy_client</title>
<vendor>Servoy</vendor>
<homepage href="http://www.servoy.com/"/>
<description>Database client</description>
</information>
<resources>
<jar href="utility.jar" download="eager" version="8"/>
<jar href="utility2.jar" download="eager" version="2"/>
</resources>
<component-desc/>
</jnlp>
we dont specify the security,
Before update 19 of java 6 this was not a problem, even the 2 utility classes didnt need to be signed. But now we somehow have to sign it.
But even if we sign the 2 jars now. We still have to also add
<security>
<all-permissions/>
</security>
to all our extention jars.
This update 19 breaks so many things for our product this way.
One thing is that we have a product that can be extended by plugins. So those extensions are not provided by us but by 3th party plugin developers. Now all those developers need to sign there code and make sure that all there jnlp files will generate that security tag also, even if they dont need anything os specific.. Why is the security not inherited from the main jnlp file?
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
try the above jnlp files including the use of extentions.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
I get a message that signed and unsiged code is being tried to run (which is not true! and when press yes in that dialog that i want to block it i get this:
ava.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost:8080/utility.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1400(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.getResource(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.first.jar.Main.main(Main.java:12)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
REPRODUCIBILITY :
This bug can be reproduced always.
SUPPORT :
YES
Release Regression From : 6u19
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.