JDK-6629341 : Plugin2: Backward Compatibility issue after secure properites check is introduced
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows
  • CPU: generic
  • Submitted: 2007-11-13
  • Updated: 2011-01-26
  • Resolved: 2008-01-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b11Fixed
Related Reports
Duplicate :  
JDK-6655272 - can't set important Java properties for OOPlugin
Relates :  
JDK-6643379 - Filter out insecure JVM command-line arguments from deployment.properties
Description
This CR is filed to track the potential backward compatibility issue in Plugin2 after secure properties check feather is implemented.

In the new plugin2, any insecure system properties and java arguments in deployment.properties required applets to be signed. This is true on both vista and non-vista platforms. On vista platform, deployment.properties file is in a low integrity location. So it is untrusted by default. On non-vista platform, this creates incompatibility issue with classic java plugin. In the old plugin, unsigned applets can still run.

We may have to rethink the current implementation if the compatibility impact is significant.
Comments
EVALUATION A user on the java.net forums indicated that debugging of applets doesn't work with the new Java Plug-In. Normally users specify -Xdebug -Xrunjdwp:... via the Java Control Panel to enable debugging of applets. It is likely that in the build they were testing they were receiving ClassNotFoundExceptions due to the specification of the insecure -Xrunjdwp command-line argument. In build 10 the fix for 6643379 inadvertently further broke this functionality, since the insecure -Xrunjdwp command-line argument would be filtered out. To solve this problem, the JVMParameters class was refactored to contain two sets of arguments: trusted and untrusted. Trusted arguments come from deployment.properties and are specified via the Java Control Panel. Even insecure JVM arguments may be specified here without affecting the "secure" status of the target JVM. Any arguments specified via the java_arguments HTML parameter go into the untrusted set and have the same semantics as before. Introduced a separator argument ("--") used to indicate to the JP2Launcher on Windows Vista the boundary between the trusted and untrusted arguments. Additionally, a check for the -Xdebug flag was added and the browser-side heartbeat thread (which is only a last safety measure to avoid browser hangs) disabled if it is present, to avoid having the target JVM abruptly torn down if the debugger is stopped at a breakpoint for a long period of time. Tested with a new regression test as well as the regression tests for 6625351, 6640436, 6643379, and the unit test for the JVMParameters class, both with and without the use of the JP2Launcher normally used only on Windows Vista.
03-01-2008
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6629341.1 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6629341/
03-01-2008
EVALUATION User shemnon on the java.net forums has pointed out that the abovementioned solution does not work; it breaks the ability to debug applets by specifying command-line arguments like -Xdebug -Xrunjdwp from the Java Control Panel. Reopening this bug. We will have to solve it by treating the command-line arguments from deployment.properties as trusted.
02-01-2008
EVALUATION It has been decided to not allow insecure system properties to be specified via deployment.properties at all, due to what would be necessary inconsistencies between platforms, in particular Windows Vista and everything else. This has been addressed in a different fashion under 6643379. Closing this as a duplicate of that one for tracking purposes.
19-12-2007