Bug ID: JDK-8025726 Certificate rule in DRS does not work for Java Web Start app when caching is turned off

Versions (Unresolved/Resolved/Fixed)

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 7	JDK 8	JDK 9
7u71Fixed	8u20Fixed	9Fixed

Testcase:
1.) Use 7u40-b43

2.) Open the Java ControlPanel and turn off caching

3.) Setup DRS with the hash from a certificate (in the example below it is the hash from the Oracle cert)

<ruleset version="1.0+">
  <rule>
    <id>
      <certificate hash="794F53C746E2AA77D84B843BE942CAB4309F258FD946D62A6C4CCEAB8E1DB2C6" />
    </id>
    <action permission="run" />
  </rule>
</ruleset>


4.) Open any Java Web Start application


Actual:
A warning message called "Do you want to run this application ?" is shown to the user before the apps starts.

Expected:
no interactive warnings at all, the app simply starts.

Comments:
When I open a signed applet, everything works as expected, I don't see any security warnings.
However, when I open a signed Java Web Start app, I see the security warning.

When I setup DRS with a location id (e.g. *.oracle.com), everything works as expected for both signed Java Web Start app and signed Java applets. 

When I enable caching, it also works as expected.

Reproducible on both Windows and Linux.

Conclusion:
The issue only occurs if the ruleset is about a certificate rule AND it is a Java Web Start app AND Java cache is turned off. Cross platform problem probably.

need to implement the dummy methods getCertificates() and getCodeSigners() in DownloadEngine.createTemporaryResource() webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.9.0/8025726/deploy/webrev/ automated unit test included.
20-03-2014
created backport to 8-pool, since we have no known way to prevent this problem, would like to defer to 7-pool till we do.
03-01-2014
The underlying problem is the implementation of DownloadEngine.downloadResourceToTempDir() is incomplete since reimplementation of cache using com.sun.deploy.model. The method used, createTemporaryResource() returns a resource object with dummy implementation for the following methods: public CodeSigner[] getCodeSigners() { return new CodeSigner[0]; } public Certificate[] getCertificates() { return new Certificate[0]; } This means anyplace other than coming from classloader code or JNLPSignedResourceHelper (where CodeSource is given) will see empty list of signers (or Certs if running 1.4 jre). This could be fixed (implemented) by mimicking code in CacheEntry that extracts certificate info from jars (or similar thing is also done in com.sun.javaws.SigningInfo) but is a fairly major effort. suggest deferring from 7u55 .
02-01-2014
defer request changed to 7u55 after discussion with Andy
29-10-2013
SQE ok to defer from 7u51.
22-10-2013
request to defer to 7u60: not a showstopper for 7u51, not a common scenario.
21-10-2013
Affected tests: JawsLocalSecurityPolicyTest::testLSPCertBlock_CacheDisable_High JawsLocalSecurityPolicyTest::testLSPCertBlock_CacheDisable_Medium JawsLocalSecurityPolicyTest::testLSPCertBlock_CacheDisable_VeryHigh JawsLocalSecurityPolicyTest::testLSPCertRun_CacheDisable_High JawsLocalSecurityPolicyTest::testLSPCertRun_CacheDisable_Medium JawsLocalSecurityPolicyTest::testLSPCertRun_CacheDisable_VeryHigh JawsLocalSecurityPolicyTest::testLSPCertDefault_CacheDisable_High JawsLocalSecurityPolicyTest::testLSPCertDefault_CacheDisable_Medium JawsLocalSecurityPolicyTest::testLSPCertDefault_CacheDisable_VeryHigh
21-10-2013
regression_test_src: http://sqe-hgi.us.oracle.com/hg/index.cgi/8/deployment_int_ws/file/ccaca784cd8c/new_framework/tests/javaws/JawsLocalSecurityPolicy/src/JawsLocalSecurityPolicyTest.java
10-10-2013