[patch] RFC: Netx plugins

[Francis Kung]

Hi,

>> 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.
> 
> It's fine to change the current behaviour (i.e., require removal of 
> stamps/icedtea-compile.stamp to force a rebuild) as a convenience for 
> people working on tools.jar/netx.jar.

I've assumed that more people will be working on OpenJDK than 
netx/tools.jar, and so those who would find it convenient can add the 
touch themselves (ie I have that in my local tree =)  )

>> - combined the icedtea-plugin and icedtea-jnlp-launcher patches into 
>> one file so they apply/revert cleanly
> 
> This is fine.
> 
>>
>> - 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.
> 
> I think keeping this optional (disabled by default) is a good idea until 
> we've done a security analysis of NetX and the implications of running 
> applets through it.

That's similar to my thoughts.  While I'm now fairly comfortable with how 
Netx works, I haven't done anything like a comprehensive security audit...

>> - 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?)
> 
> Can the NetX packages be included in rt.jar so that no use of reflection 
> is required?  Can NetxPanel and PluginBridge go in the sun.applet 
> package to eliminate the API changes?

Originally I was looking for ways to avoid the API changes... I've 
considered:

a) putting NetxPanel and PluginBridge in rt.jar; however that would mean 
rt.jar requires netx.jar in order to compile and run... in which case, we 
may as well put all of the netx code in rt.jar somewhere and eliminate 
netx.jar altogether.  I don't think rt.jar should depend on an external 
module.

b) putting NetxPanel and PluginBridge in the sun.applet package, but 
leaving them in netx.jar; the classloader chokes hard on this =)

c) make a version of PluginMain in netx.jnlp.* and have gcjwebplugin.so 
call directly into this, instead of calling into sun.applet.PluginMain; 
however there would be a lot of duplication of code between sun.applet 
and netx.jnlp if we took this approach.


>> 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.
> 
> I'd say just remove the dialog and run all applets in the untrusted 
> sandbox until Josh's patch lands, which should be fairly soon.  We'll 
> probably just re-use Josh's dialog anyway.

Sure.  I saw Josh had a large netx commit yesterday, but haven't had a 
chance to go over it and possibly integrate any relevant changes yet.

>> 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).
> 
> Once the NetX work is complete and stable we should probably modify 
> AppletViewer in the same way that we modify PluginAppletViewer, but for 
> now it's fine to leave the standalone appletviewer as-is.

Sounds good to me.

Cheers,
Francis