JDK-8135227 : DRS 1.3 enhancements doesn't work as expected when load no href jnlp by "javaws "
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-09-09
  • Updated: 2018-03-30
  • Resolved: 2015-09-10
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 8 JDK 9
8u72Fixed 9 b83Fixed
Related Reports
Relates :  
JDK-8199317 - Launched from browser, UTF-8 encoded argument in a JNLP file is not correctly passed to application
Relates :  
JDK-8199304 - javaws.exe failed to launch UTF-8 encoded JNLP file
Description
Loading no href jnlp by "javaws <local_path_of_jnlp_file>" does not work as far as DRS1.3 enhancement is concerned. 

ENV: win7/x64/9-client nightly build #3316

Steps to reproduce:
1). Import self ca cert to JCP -> Security -> Manage Certificates -> Singer CA.
    http://kgb.us.oracle.com:8080/DRS13Manual/lib/self.valid.cert
2). Set up rule set
    http://kgb.us.oracle.com:8080/DRS13Manual/lib/DeploymentRuleSet.jar
    For rule set content, see http://kgb.us.oracle.com:8080/DRS13Manual/lib/ruleset.xml
3). Download jnlp file testCertsignedAllpermissionJNLPNoHref.jnlp from http://kgb.us.oracle.com:8080/DRS13Manual/html/testApps.html
4). Save it to  C:\test
5). Run javaws with local file path arg: javaws C:/test/testCertsignedAllpermissionJNLPNoHref.jnlp
6). If a valid security warning dialog will show up which should not since the SHA-256 checksum of this jnlp is matched to the hash attribute of the "jnlp-checksum" sum elements in ruleset.xml, then this bug is reproduced.

Note:
1. "javaws -browser <local_path_of_jnlp_file>" works fine(a dialog saying "Application Allowed by Deployment Rule Set" will show up).
2.  If launch jnlp by double click jnlp file or right click jnlp and open with "Java(TM) Web Start Launcher", it works fine.
3. If load jnlp by clicking on the link  testCertsignedAllpermissionJNLPNoHref.jnlp in a browser from http://kgb.us.oracle.com:8080/DRS13Manual/html/testApps.html, it works fine.
Comments
Verified with jre9-b175 on win10/x64.
03-07-2017
Verified with http://jre.us.oracle.com/java/re/jdk/9/jdk9-client/b82_2015-09-15-0923_3389/bundles/ on win7/x64.
17-09-2015
The fix changes the code in XMLFormat.setSourceURL() to not relay on wheather or not you are going to delete the given file. This problem was caused by trying to create "." as a legitimate codebase, for apps that could only be launched from command line with full path or file url to the app. Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1331 change also includes change to never copy file in native code. copying file is no longer necessary, though this didn't turn out to be the cause of this problem.
09-09-2015
but wait - there's more. - may not be non-symmetry of native Read and Save methods at all. in XMLFormat.setSourceURL(), we try to set the original location of the jnlp file, based on whether JnlpxArgs.shouldRemoveArgumentFile() is true. This code is trying to "guess" if the file arg passed to java code is from where the app really is (on local file system) vs where browser downloaded it to
09-09-2015
it seems the native methods "ReadFileToBuffer()", and "SaveBufferToTempFile" are not entirely symetrical, (see jdk.javaws/share/native/util.c) so when we make a copy of the jnlp file, we are making some insignificant change that is changing the checksum hash. The recent change to use -browser, preserves the original file (no copy is made in native code) so the DRS 1.3 feature works only in that case. The fix would be to not make a copy in either case, since the original purpose of making a copy was that browsers would delete the file once the helper app exited, and there is now no browser left that does that.
09-09-2015
in this example, the codebase in the jnlp file is: codebase="http://kgb.us.oracle.com:8080/DRS13Manual/jnlp/" the jar file is not within that, it is at: jar href="../classes/CaSignedHelloWorld.jar" (or http://kgb.us.oracle.com:8080/DRS13Manual/classes/CaSignedHelloWorld.jar ) the DRS rule has location: <id location="http://kgb.us.oracle.com:8080/DRS13Manual/jnlp/"> so even though the jnlp file is covered by the rule, the jar isn't. but wonder of wonders ! I do get different behavior when running "javaws xxx.jnlp" vs "javaws -browser xxx.jnlp" when xxx.jnlp is a copy of testCertsignedAllpermissionJNLPNoHref.jnlp still investigating ...
09-09-2015
Affected tests: RULE JawsLocalSecurityPolicyTest::testJnlpChecksumMatchMainAndExt any any RULE JawsLocalSecurityPolicyTest::testJnlpChecksumMatchMain_Ext any any RULE JawsLocalSecurityPolicyTest::testJnlpChecksum_Negative_NoneRunAction any any RULE JawsLocalSecurityPolicyTest::testMultipleJnlpChecksum_SignedAllPer any any RULE JawsLocalSecurityPolicyTest::testMultipleJnlpChecksum_SignedSandbox any any RULE JawsLocalSecurityPolicyTest::testMultipleJnlpChecksum_Unsigned any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_ExpiredJre any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_ExpiredSigned any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_SelfSigned any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_SignedAllPer any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_SignedSandbox any any RULE JawsLocalSecurityPolicyTest::testSingleJnlpChecksum_Unsigned any any
09-09-2015