JDK-7177094 : Regression: App fails w/ "application requesting unrestricted access",cache failure in 6u33 and 7u5
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u33,7,7u5
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2012-06-14
  • Updated: 2013-10-23
  • Resolved: 2012-06-20
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 JDK 7 JDK 8
6u33Fixed 7u5Fixed 8 b44Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
Applet encounters error with 6u33 and 7u5. 

#### Java Web Start Error:
#### Unsigned application requesting unrestricted access to system

Unsigned resource: http://somewebsite.domain/current/somejar.jar
6u31 was able to verify the jar successfully and start the application.


See Comments.

Comments
Verified on x86 Win 7 using JRE 8-b112 promotion. Application http://jar.theice.com/current/webice_launch.jnlp launched fine
23-10-2013

EVALUATION This bug has been fixed and new downloads made available: http://java.com and http://www.oracle.com/technetwork/java/javase/downloads/index.html New builds of 6u33 and 7u5 have been released. Downloads of 6u33+ and 7u5+ after July 12, 2012 will have this fix.
12-07-2012

EVALUATION Two problems needs to be fixed: 1. Original fix in 7u5/7143868 only sets knownToBeSigned = false to reset cached validation results, not that is not sufficient. That will reset only SigningInfo.isKnownToBeSigned, but not SigningInfo.isKnownToBeValidated. To reset cached validation results, validationTimestampt needs to reset to 0 also. Simiar reset code is doing same in existing code too. This will take care of upgrade from 7u3 or 7u4 scenario. 2. Now for the corrupted cache caused by 7u5 - it seems like the code in JNLPSignedResourceHelper.checkSignedResourcesHelper has a problem. When it detected sInfo[i].isKnownToBeSigned() == false, it thinks the cached JAR is not signed and throw UnsignedAccessViolationException. But isKnownToBeSigned seems to only indicate whether the cached entry certificate has been pre-validated before, but not an actual indication of whehter the cached JAR is signed or not. It seems to me when isKnownToBeSigned return false - it just means the cached results should not be trusted, but not the JAR is unsigned. (See CacheEntry.isKnownToBeSigned) Instead of throwing the UnsignedAccessViolationException, I think we should just revert to full re-validation and continue instead. testcase: make sure the application http://jar.theice.com/current/webice_launch.jnlp works in both 7u3 upgrade scenario and broken 7u5 cache scenario.
18-06-2012

EVALUATION reverting the change in 7143868 does help the original upgrade scenario, ie: 7u4 -> 7u5+revert, app will launch. But once someone ran 7u4->orig-7u5 and has the problem, the reverted change does not help. It will continue to fail unless you clean cache. more investigation needed
15-06-2012

EVALUATION I can reproduce the problem now. It happens when user ran the application with previous release of Java (e.g 6u31 or 7u3), have application in cache, and then upgrade to 6u33/7u5 and run the same application again. Looks like it's a bug in our code in 6u33/7u5. Workaround is to clear cache either via java control panel or command line "javaws -uninstall", and then launch with 6u33 again.
15-06-2012

WORK AROUND There are two solutions: 1) Clear cache either via java control panel or command line "javaws -uninstall", and then launch the application again. 2) Install 6u33/7u5 again. See: http://java.com/en/download/help/clearcache_upgrade.xml Notes: Fixed on a built that was made available after the GA of 6u33. If you experience this problem check your build number and if not b04 get the latest JRE. Fixed on a built that was made available after the GA of 7u5. If you experience this problem check your build number and if not b06 get the latest JRE.
15-06-2012