[FIXED] Jre6u19 security popup

[Mickelukas]

Hi,

With 6u19 a new security "feature" got introduced that gives a very nasty message when using the applet loader. Would it be possible to sign the next version of the applet loader with the trusted library attribute in the manifest (if that would help)?

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

[kappa]

ok, fix looks simple enough we just need to add

Trusted-Library: true

to the manifest files of the LWJGL jars.

[kappa]

hmm OK from my tests it looks like for applets only the lwjgl_util_applet.jar needs to be tagged with 'Trusted-Library: true' due to the way the appletloader works.

However for JWS to work all the jars that need to be signed will probably have to be tagged:
lwjgl.jar
jinput.jar
possibly all the native jars

[kappa]

looking at the lwjgl build file doesn't look like we compile jinput.jar, so guess the JInput project will have to separately add

Trusted-Library: true

to the manifest file in the jinput jar.

[kappa]

fixed and added to the LWJGL build file in svn, this will now be included as part of LWJGL 2.4.

Mazon/Endolf: for the sake of completion and Java Web Start the manifest file in jinput.jar should also include 'Trusted-Library: true'. However I guess since LWJGL doesn't sign jinput.jar anyway anyone who is going to use jinput.jar is gonna sign all his jars hence not run into this mixed unsigned/signed jar dialog.

Mickelukas: thanks for pointing this out.

[Mickelukas]

Great work

[Endolf]

looking at the lwjgl build file doesn't look like we compile jinput.jar, so guess the JInput project will have to separately add

Trusted-Library: true

to the manifest file in the jinput jar.

Nope, I won't do this, and will revert the change should anyone try and commit it to JInput . This is a decision the application developer has to take, not the library developer. I would not expect any unsigned jar to contain that property in the manifest.

As an application developer, if I sign code, or decide I do trust a library, I will add the property to the manifest.

I guess the lwjgl build should be modified to add that property, as it's LWJGL that has decided to trust JInput

That's my opinion anyway.

Endolf

[Endolf]

Some of what they broke in u19 might be fixed

http://java.sun.com/javase/6/webnotes/6u20.html#otherbugfixes-6u20

[Endolf]

I didn't install u19, I just installed u20 and neither my webstart app (uses LWJGL) or jinput applet present any extra warning dialogs. They are unchanged so as they were before this sorry mess started.

HTH

Endolf

[Mickelukas]

fixed and added to the LWJGL build file in svn, this will now be included as part of LWJGL 2.4.

Mazon/Endolf: for the sake of completion and Java Web Start the manifest file in jinput.jar should also include 'Trusted-Library: true'. However I guess since LWJGL doesn't sign jinput.jar anyway anyone who is going to use jinput.jar is gonna sign all his jars hence not run into this mixed unsigned/signed jar dialog.

Mickelukas: thanks for pointing this out.

Trusted library is gone in version 2.5 and I now get the mixed code "error" message again. Was it removed due to a better way being available? (Except for having to resign everything yourself).

Mike

[kappa]

yes Trusted-Library is gone, the only jars that needed it for lwjgl applets to work were lwjgl_util_applet.jar and lzma.jar, however they are now both signed with LWJGL 2.5, so the extra complexity is not needed.

As for any jars in the al_jars parameter you can use a mix of signed and unsigned without a problem.

[Mickelukas]

Then I'm a bit lost, what would cause me to get a warning about mixed code, any ideas?

I'm using a 2.5 applet and I didn't sign my own jar.

Mike

[kappa]

double check that your using both lwjgl_util_applet.jar and lzma.jar from LWJGL 2.5.

If needed open the jar and check the manifest and make sure it doesn't have any of the Trust-Library stuff in there.

Lastly double check that both jars are signed.

[kappa]

oh and just for good measure, if the above doesn't work, clear you java cache, could be that one of the older jars is somehow still lurking about.

as long as the jars in the archive parameter are not mixed (unsigned/signed) you shouldn't really get that warning.

[Mickelukas]

Thanks for the tips but it still gives the message.

Removed the cache folder from Users.
Cleared the classloader cache.
Tried a computer that never loaded the app before.

Made sure that the applet tag was correct:

archive="lwjgl_util_applet.jar, lzma.jar"
<param name="al_jars" value="lwjgl.jar.pack.lzma, lwjgl_util.jar.pack.lzma, Dreamlandz.jar">

Opened the two jars in archive and they both have the oddlabs files and the manifests are as following:

Manifest lwjgl_util_applet.jar:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 16.0-b13 (Sun Microsystems Inc.)
Sealed: true

Name: org/lwjgl/util/applet/AppletLoader$2.class
SHA1-Digest: VGySNc8u8l+LPenm3X40ke1J/ww=

Name: org/lwjgl/util/applet/AppletLoader$4.class
SHA1-Digest: k4AbNG+AIucxmk02t255k489XBU=

Name: org/lwjgl/util/applet/AppletLoader$3.class
SHA1-Digest: LoiLkLFb554OVpcZdS/Fsw9VqzU=

Name: org/lwjgl/util/applet/AppletLoader$1.class
SHA1-Digest: 3Z3arerU09bnpVJDElXhGsZ5NNc=

Name: appletprogress.gif
SHA1-Digest: rM9NIU5I32IFSEB+qKQDHaB7GnU=

Name: appletlogo.png
SHA1-Digest: IoYe7F8u3zNq00oxtPlyIeIQCCs=

Name: org/lwjgl/util/applet/AppletLoader.class
SHA1-Digest: 9A0aGka82Gs8u5MFw9NyOoximgY=

Manifest lzma.jar:

Manifest-Version: 1.0
Sealed: true

Name: LZMA/LzmaInputStream.class
SHA1-Digest: ySYG0OU+ANZ8eyCl9B5gPlgxIas=

Name: LZMA/CRangeDecoder.class
SHA1-Digest: f8p2nI7/tS5qxkLvFQac0QTiwgE=

Name: LZMA/LzmaException.class
SHA1-Digest: bpkMhLjITTAYEz2c5uZb46fHJKU=