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 :
all Operating systems with Java 6_19

A DESCRIPTION OF THE PROBLEM :
in this document:

http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#manifest

"Trusted-Library Attribute

For applications and applets that are designed to allow unsigned components, the Trusted-Library attribute should be used. No warning dialog will be displayed and an application or applet may load jar files containing untrusted classes or resources"

That seems to me that if i add that to our signed jar that then our code can access the unsigned jars and use that code. but i can class not found errors.

Now i am curious about that this line

"This attribute prevents signed components in an application or applet from being re-purposed with unsigned components"
and
"The trusted library code components cannot be replaced and trusted library classes and resources are isolated from all untrusted components"

What does that mean? Can jars that are signed and have that property access code in unsigned jars?
Or are they really completely isolated from each other? But if that is the case what is then then the use case of this property? Because it cant access/use untrusted components anyway so then it seems to be just the same as the "Trusted-Only" property.
The biggest problem we have is that we want to trust anything that comes from the same server of the first (main) jar that is signed and has that property.

This is because Servoy has an application deployed by webstart. But we have a plugin architecture so others can extend our base application by creating plugins Those plugins can be created by our customers them selfs or can by bought in by 3th party plugin providers.

The can just drop in a plugin.jar in a folder on the server or a plugin.jar and some support libs with a plugin.jnlp file.
Those plugins uses interfaces of us. And we (the base signed application) instantiate those plugins and uses them.

Problem is that we access/instantiate those plugins, and those plugins uses ofcourse interfaces from use to compile..

So how will this work? Should everything now be signed? This will be a serious burden for all our customers and third party plugin creators.

Somehow we just want to say, everything that comes from the same server is validated by us and is correct.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
opening this url:

http://test-servoy-02.servoy.com:9090/servoy-client/servoy_client.jnlp

will now show a different bug (already reported) but that will try to download plugin classes that are not signed, if you open this:

http://test-servoy-02.servoy.com:9090/servoy-client/servoy_client.jnlp?raw=true

you will see the base jars that are all signed and we can provide extra manifest attributes just fine

But in the unsigned.jnlp or in all the plugin/xxxx.jnlp files those dont have to be from us but they can come from our customer it self.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That we can have mxied signed content that just works without constantly getting that dialog (and not completely disabling that verification on every client)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
all our customers (and there customers) will now not upgrade to java 6_19 because of this. This is really the only workable situation for us.

Because this minor upgrade of java 6, completely broke our product.

SUPPORT :
YES

Release Regression From : 6u18
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.