This discussion is archived
8 Replies Latest reply: Aug 6, 2013 11:11 AM by c77cebf0-d019-49a1-9407-c855c674b630 RSS

How to avoid SecurityException with JRE 1.6.0_19 update

843798 Newbie
Currently Being Moderated
Hi,

I have an applet which is present in a signed jar. This applet uses another jar file which is unsigned.
On launching the applet I get the Mixed code warning which I want to avoid.

To solve this issue, I added "Trusted-Library: true" to the unsigned jar which is being used by my applet.

But, it still throws SecurityException. I tried this with JRE update 20 as well but problem persists.

Can someone please help me with this? How to avoid getting the Warning message when I have to use an unsigned jar.

Thanks!

-Raghvendra
  • 1. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    793415 Pro
    Currently Being Moderated
    What is the exact (copy/pasted) exception you are seeing? Does it point to the signed Jar, or the unsigned Jar?
  • 2. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    843798 Newbie
    Currently Being Moderated
    Any jar file that you put the manifest attribute in ... must then be signed.

    I believe what you need to do is put the Trusted-Library manifest in your "signed" jar file ...

    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. This attribute prevents signed components in an application or applet from being re-purposed with unsigned components.

    All classes and resources in a jar file containing this manifest attribute must be signed.

    In a mixed code application or applet, all signed classes and resources must be included in jar files that contain the Trusted-Library attribute.

    All trusted library jars are loaded into a separate dedicated class loader which is unique to the application or applet. The trusted library code components cannot be replaced and trusted library classes and resources are isolated from all untrusted components.
  • 3. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    843798 Newbie
    Currently Being Moderated
    I am facing a similar problem as posted in this thread. The applet is present in a signed jar which loads the classes from the 3rd party lib jar which is unsigned. In order to avoid the security warning, I have added "Trusted-Library: true" to the manifest file of the signed applet jar. After this, when the applet runs and tries to load the classes from the unsigned 3rd party jar, I see NoClassDefFoundError in the java console.

    Does this exception relate to the different class loaders used? Any clues?
  • 4. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    843798 Newbie
    Currently Being Moderated
    I have the same issues, just with a configuration file from an unsigned jar. See:
    [http://forums.sun.com/thread.jspa?threadID=5434801]

    What is it we are missing?

    Edited by: H.Dohlmann on May 6, 2010 7:47 AM
  • 5. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    843798 Newbie
    Currently Being Moderated
    We are also seeing the same issue. The problem with the Trusted-Library workaround (as described in http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html) is that it doesn't appear to handle the case where our signed jar classes need to call into unsigned jar classes. Adding the Trusted-Library attribute to our signed jar causes it to be loaded in a different classloader than the unsigned 3rd party jar(s), so of course NoClassDefFound errors will occur when trying to load these classes. I would think this is a very common case for most Java applet developers. Furthermore, Sun also seems to say that the workaround can be employed by target end users/administrators, who would simply add the attribute to existing production signed jar files.
    Does anyone know if there any workaround for the mixed-signed case that will allow signed jars calling into unsigned 3rd party jars? I do not want to start adding fancy classloader switching code to my applets.
  • 6. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    830287 Newbie
    Currently Being Moderated
    in the http://download.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html

    it says,

    Code in a jar file that is to be marked with the Trusted-Library manifest attribute may need to be modified slightly if it uses calls that are class loader dependent, such as the single parameter version of Class.forName(), Class.getResource(), and Class.getResourceAsStream(), some variants of java.util.ResourceBundle.getBundle(), and any other methods which operate relative to their immediate caller's defining loader. Changes only need to be made if the requested class or resource might be found in a jar file which is not a Trusted-Library (and is therefore loaded by the normal Web Start or applet class loader).

    and the problem is how to modify?

    for example, i need to init log4j in a applet main class, but log4j.jar is unsigned, how to change the following line in applet main?

    static Logger logger = Logger.getLogger(ArcTest.class.getName());

    hope there is some guy who can figure out the solution,

    this problem is very very disgusting!!!
  • 7. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    PhHein Guru Moderator
    Currently Being Moderated
    Please don't post in threads that are long dead and don't hijack other threads. When you have a question, start your own topic. Feel free to provide a link to an old post that may be relevant to your problem.

    I'm locking this thread now.
  • 8. Re: How to avoid SecurityException with JRE 1.6.0_19 update
    c77cebf0-d019-49a1-9407-c855c674b630 Newbie
    Currently Being Moderated

    This question is still valid and it's in the top 5 google searchs for trusted-library issues.

     

    If there was a satifactory answer anywhere it's not on these forums perhaps we could bump this to get a fresh answer to the old problem?