4

I have an applet which is present in a signed jar. This applet uses another 3rd party 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!

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
raghvendra
  • 285
  • 5
  • 18
  • Since it is 3rd party jar I think we cannot sign it, some legal issue. Is there any thing that we can do using the Trusted-only or Trusted-Library manifest attributes. I thought that's what their purpose was. – raghvendra Aug 23 '10 at 09:18
  • 2
    think about it: if the library is not signed, but your app is signed, then someone bad could easily manipulate the library to do something you don't want, distribute your signed code together with the unsigned, modified library and do bad stuff with your name on it. You don't want that, right? – Joachim Sauer Aug 23 '10 at 09:22

1 Answers1

2

Use your tool chain to sign the 3rd party JAR with your key.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Can we sign a 3rd party jar with our signature? meaning, will that be legal? – raghvendra Aug 23 '10 at 09:19
  • 1
    @raghvendra: check with your legal department for that. But from what I see, it is not an uncommon practice. – Joachim Sauer Aug 23 '10 at 09:26
  • 1
    You can sign it, but make the signature say that you're signing on behalf of third-party providers. Like that, it's *you* that is making the assertion that the code is OK, but you're not claiming ownership. – Donal Fellows Aug 23 '10 at 09:41
  • @Donal You are also putting your name against the code being secure. Being secure is a different kettle of fish from not being malicious. – Tom Hawtin - tackline Aug 23 '10 at 19:00
  • @Tom: Yes, but that's why you should only grant exactly what is needed for the code to do its job. Don't give access to the whole filesystem when only only a tiny bit will do; don't give the ability to open any socket when connecting to your server (with known IP address) is enough. – Donal Fellows Aug 23 '10 at 20:00
  • @Donal Whilst that can be useful, it's very rare to be done in practice. It's difficult to work out what the exact permission should be (they'll be hidden in libraries) and it doesn't tend to achieve much. – Tom Hawtin - tackline Aug 23 '10 at 21:05
  • @Tom, what would you recommend doing then? – Thorbjørn Ravn Andersen Jan 27 '11 at 11:51
  • @Thor: Either do the "right" thing (which is: Analyze the whole code, write a specific security manager for it, etc) or the "practical" thing: Just sign it and hope for the best. It really depends on what you *need*. If you employer is paying for a full inspection since there is a legal demand for it, then do that. If you're just writing an applet for yourself, why bother? – Aaron Digulla Feb 01 '11 at 04:31