[patch] RFC: Netx plugins

[Joshua Sumali]

Lillian Angel wrote:
> Hi,
>
> A couple of concerns...
>
> Francis Kung wrote:
>> Hi all,
>>
>> See attached for a patch that changes gcjwebplugin to run applets 
>> through Netx, consolidating IcedTea "web services" into one place.  
>> An overview of the major / possibly contentious changes:
>>
>> - added an "icedtea-compile" stamp in the makefile for the actual 
>> OpenJDK build.  This is needed as the new IcedTea is used to build 
>> netx (I've introduced some API changes, relaxing visibility in 
>> sun.applet.*).  Note that the lack of "touch 
>> stamps/icedtea-compile.stamp" is intentional, to remain consistent 
>> with current behaviour.
>>
>> - combined the icedtea-plugin and icedtea-jnlp-launcher patches into 
>> one file so they apply/revert cleanly
>>
>> - need to pass --enable-netx-plugin to enable this (considering it an 
>> experimental feature); all this does is create netx.jar in 
>> j2sdk/jre/lib with netx code in it.  If this jar is missing, we fall 
>> back to using the old Sun plugin code (see the reflection bit in the 
>> sun.applet.PluginAppletViewer constructor).  I'm creating a new 
>> netx.jar, instead of using j2sdk/lib/tools.jar (like javaws does), so 
>> that the plugin can be distributed with a JRE rather than requiring 
>> the full SDK.
>
> Should --enable-netx-plugin be set by default? In my opinion, 
> everything is experimental. There should only be an option to disable 
> netx.
I think it should also be enabled by default. Perhaps the jar name 
should be something less general than netx.jar though -- perhaps 
netx-web-plugin.jar ?
>
>>
>> - modified the default security policy to grant all permission to 
>> ${java.home}/lib/netx.jar  (is this safe, or is there a better way to 
>> accomplish this?)
>
> We should never allow a user to allow an application to grant all 
> permissions. 
Unless that application is signed and the user trusts the signer and 
publisher (as is the case with jnlp applications). It probably doesn't 
apply too well to this situation though, since I don't think we'll be 
signing that jar.
> I think we need to make these type of apps as secure as possible and 
> be sure we ask each time. What about having a whitelist? Also, I don't 
> think it would be in the best interest to have the default security 
> policy so lax.
>
While it's a good idea to ask each time, won't it be too much to be 
asking to run netx.jar, then also asking to grant full permission to the 
actual applet? Further yet, should we want to ask the user for 
permission to grant all access to ${java.home}/lib/netx.jar, would 
netx.jar be showing the permission dialog, and then changing the default 
security policy?
>>
>> This isn't complete, but it's finally in a working state and has been 
>> in a private repo for too long... currently a dialog is displayed for 
>> all applets asking if the user wants to grant it full permission or 
>> not.  
>
> Is the dialog displayed for each applet or just the first applet is 
> loaded? if "grant full permissions" is selected, are the permissions 
> granted for all applets or only that particular one?  I think we 
> should display if for each applet. (Not sure if I misunderstood the 
> previous point as well)
Yes, probably display it for each applet. The above policy is OK, but 
perhaps it could be improved by letting the user choose what kind of 
permissions to allow on startup (i.e. file read, file write, clipboard 
access, etc) or maybe even show dialogs on each type of access, with the 
option to "always allow this action" for the rest of the applet's 
runtime? I could imagine this would involve a bit more work though...
>
>> The plan is to re-use Josh's work on Netx jar-verifying to tweak this 
>> dialog and only display it when needed; we can also create a 
>> consolidated JNLP/plugin settings GUI (cache management, trusted 
>> certificates, etc).
Yes, this might be a good idea. I've still yet to figure out how to keep 
track of who we're trusting in terms of code signers and certificates.
>>
>> Comments, or good to commit? 
>
>
> Hold off for now. Have you run your patch by fitzsim?
>
>
> Great work :)
> Lillian
Looking good though!
Josh