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 (http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html)
ok, fix looks simple enough we just need to add
Trusted-Library: true
to the manifest files of the LWJGL jars.
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
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.
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.
Great work :)
Quote from: javalwjgl on April 03, 2010, 12:00:48
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
Some of what they broke in u19 might be fixed
http://java.sun.com/javase/6/webnotes/6u20.html#otherbugfixes-6u20
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
Quote from: javalwjgl on April 03, 2010, 13:38:11
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
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.
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
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.
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.
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=
hmm, odd, can you try if http://www.lwjgl.org/applet/ works for you.
Bit difficult to tell further without looking at the applet, have you got it uploaded somewhere?
also are you still on JRE6u19? or have you updated to JRE6u21?
This is insanely weird but I guess you know why :)
I solved it and figured out what it was. I had a parameter:
<param name="al_logo" value="pictures/appletlogo.png">
If I use the default lwjgl picture (instead of my own) it works great and no popup appears.
Any idea how to solve it? It's nice to have my own logo there because I made my own loading screen look exactly the same so it seems like you're just loading one component.
Mike
are your logo's insides jars? try put them outside the jar if so.
The logo is outside the jar. It doesn't matter if I point it to "pictures/appletlogo.png" or "mylogo.png", I still get the warning.
hmm, I can reproduce this locally, loading an unsigned image causes java to throw a mixed jar warning.
/me shakes fist at Oracle.
This means the classloader is blocking any resources that aren't signed.
guess you'll just have to work with the LWJGL logo's or sign your own jars for now.
I'll see if can find a solution to this for LWJGL 2.6.
public Image getImage(String s) {
try {
URL url = new URL(getCodeBase(), s);
if (url == null) {
System.out.println("Image not in jar");
url = getClass().getResource("/"+s);
}
Image image = null;
try {
image = ImageIO.read(url);
} catch (Exception e) {
url = getClass().getResource("/"+s);
image = super.getImage(url);
}
// wait for image to load
MediaTracker tracker = new MediaTracker(this);
tracker.addImage(image, 0);
tracker.waitForAll();
return image;
} catch (Exception e) {
e.printStackTrace();
/* */
}
return null;
}
this is a fix, except that it looks outside the jar first. Im sure there is a better solution as this is rushed, but this works at least.
1 idea is an optional boolean tag in the paramaters for "custom image" otherwise look in jar.
yet im sure there is a better way
getClass().getResource("/"+s); was causing the popup
I think getImage should remove:
getClass().getResource("/"+s);
and should only be called if:
<param name="al_logo" value="appletlogo.png">
or
<param name="al_progressbar" value="appletprogress.gif">
is used.
otherwise the line:
getClass().getResource("/"+s);
should be called.
ah awesome stuff bobjob, looks like you found the cause of the problem.
will test it out tonight.
Cool, you guys rock! :-D
ok great job everyone, especially bobjob.
oh and thx Mickelukas for finding yet again another bug :)
This problem is now fixed and a patch has been applied to the nightly builds of lwjgl.
Hopefully a LWJGL 2.6 release shouldn't be too far off, since OpenGL 4.1 support was added recently
your welcome, always a good feeling getting a bug fixed.
Just a quick check regarding the fix.
I'm using the 2.6 files that are used by the applet example and I added the line:
<param name="al_logo" value="pictures/appletlogo.png">
(where picture is a folder on the webserver relative to where the jar file is) and I still get the security window. Is it because the fix isn't in the applet example or because I'm using the parameter wrongly?
Mike
Can you try with the LWJGL nightly build #1042+, there was some tweaking with this area of code recently so might be fixed (for real this time :)).
Works like a charm, thanks :)
Mike