Fwd: Re: [RFC] PR568: LWJGL Applets fail to work with IcedTea Plugin

[Jiri Vanek]

just want to mention - I'm working on (with) several LWJGL applets.... 
And i have noticed no problem after installing icedtea-web (head).

-------- Original Message --------
Subject: Re: [RFC] PR568: LWJGL Applets fail to work with IcedTea Plugin
Date: Wed, 23 Mar 2011 11:44:37 -0400
From: Deepak Bhole <dbhole at redhat.com>
Reply-To: Deepak Bhole <dbhole at redhat.com>
To: Omair Majid <omajid at redhat.com>
CC: IcedTea <distro-pkg-dev at openjdk.java.net>

* Omair Majid <omajid at redhat.com> [2011-03-23 11:35]:
> On 10/13/2010 11:32 AM, Omair Majid wrote:
> >Hi,
> >
> >The attached patch attempts to fix PR568.
> >
> >The LWJGL applet downloads a jar to /tmp/ and then calls
> >getPermissions() using that jar as the CodeSource. Currently, since
> >there is no SecurityDesc for this new location, an exception is thrown.
> >A comment from the source code of LWJGL is:
> >// getPermissions from original classloader is important as it checks //
> >for signed jars and shows any security dialogs needed
> >The attached patch modifies JNLPClassLoader.getPermissions() to treat
> >the new jar the same way it would be treated if it was loaded by
> >initializeResources(). Currently, it checks that the jar is on the local
> >machine and the plugin is being used.
> >
> >The check for a local jar means that any jar on the local machine can
> >now be accessed by an applet (can untrusted applets do this? - they do
> >not have any file permissions). Even though a security dialog will tell
> >the user if the jar is unsigned (or any of the cases that can happen in
> >initializeResources), I am not sure if this is the best solution.
> >
> >I would also like to extend this to all JNLPs in general, but two things
> >are keeping me
> >1. I have not seen any JNLP applications using this.
> >2. I cant see a way to figure out what SecurityDesc should be used
> >(since there is no JNLP file to describe the security permissions that
> >should be granted).
> >
> >Any thoughts or comments?
> >
>
> Anyone? My personal opinion is to hold off on this for now and add
> it after a new security system is in place.
>

Agreed. We have made changes that will conflict with this patch set.
Given that this isn't an issue that will be encountered by a majority, I
too vote for post security re-design.

Cheers,
Deepak

> Thanks,
> Omair