JDK-8027821 : For signed jars without manifest "Permissions", there is still security warning dialog before Application Error (Or blocked) Dialog.
  • Type: Bug
  • Component: deploy
  • Affected Version: 7u51,7u76,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-11-05
  • Updated: 2015-07-31
  • Resolved: 2014-06-05
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
7u60Fixed 8u20Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8029245 - "Security Information" dialog shows up instead of "Application Blocked" when load signed apps whose jar is without "Permissions" attribute in manifest at High/VeryHigh level
Duplicate :  
JDK-8031998 - 7u51 still shows Applet Security Warnings talks about "blocked in future version"
Duplicate :  
JDK-8028065 - Security dialog in Java Web Start is shown before blocking dialog when main jar is missing permissions attribute
Duplicate :  
JDK-8027862 - Regression: Security warning is shown instead of Application Blocked dialog if permissions attribute is missing
Relates :  
JDK-8028065 - Security dialog in Java Web Start is shown before blocking dialog when main jar is missing permissions attribute
Description
Steps to reproduce:
1. Install the latest 8 nightly (#645) on win7-x86
2. import this cert to deployment Signer CA store so our apps will be regarded as valid CA-Signed: http://sqe-hgi.us.oracle.com/hg/index.cgi/8/deployment_int_ws/raw-file/5fe827854bc1/new_framework/lib/keyStore/valid_selfsigned_100year_keystore.cert
3. access http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/stephen/deployment_stuff/do.NOT.remove.me/bugs/lc_sqe_links/liveconnect/html/test_JS2SJ_Sandbox.html
4. Note the main jar MixedCodeAppletTLCAC.jar is missing manifest "Permissions"
5. If you see security warning dialog asking for if you want to "Run", then the issue is reproduced.

Expected:
The app should be directly blocked because of JDK-8025098.

Also:
1. the security warning dialog contains yellow warning saying that the jar missing manifest "Permissions" and will be blocked in a "future" JRE
2. after you click "Run", the apps will abort with error in trace:
========
Missing Application-Name manifest attribute for: http://localhost:8080/liveconnect/classes/MixedCodeAppletTLCAC.jar
========

So actually #1 and #2 contradict each other.
Comments
To fix this, I have removed the checks from where they were, and added them to TrustDecider and SandboxSecurity. That code will use a new AppContext property saying what the main class name is, and check each jar to see if it contains that class (to know if it is the main jar) Since this is before showing the security dialog, it will show a blocked dialog instead of first a security dialog when the first jar is a main jar without the permissions attribute. If the first jar is not main, security dialog will show for it, (as before) then application will block when the main jar tries to load. webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.9.0/8027821/ crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-111
18-07-2014
the original fix was verified with given applet and test cases in http://oklahoma.us.oracle.com/www/tests/1.9.0/8027821/ During review it was simplified (removing code to handle case where main class property stored in AppContext already had ".class" in end of value). After fix simplification, change was only retested with test cases in http://oklahoma.us.oracle.com/www/tests/1.9.0/8027821/ and not original testcase. Original testcase still fails due to checking jar for entry "MixedCodeApplet.class.class" in TrustDecider.checkMainJarManifest() see: https://bugs.openjdk.java.net/browse/JDK-8046330
11-06-2014
SQE OK to defer the risky fix from CPU14_03
28-04-2014
The fix as put in JDK9 and 8u20 has serious problems - and causes regression(s). please do not backport this fix at this time - I am opening new bug, and requesting this fix be deferred from CPU14_03
22-04-2014
critical request for 14_03: This fix is already in JDK9 and 8u20. Extra security dialog is affecting nightly testing results for SQE.
21-04-2014
The fix is in JDK9 and 8u20 - but this is against 8u11 - release team need to decide if this should be pulled into 8u11 or closed
20-04-2014
one further thing we may wish to consider. The red text that says this will be blocked in the future due to not having permissions attributes makes no sence now and should be removed - the future is now, if the main jar has no permissions attribute, it will block. (unless on ESL where the red text is omitted)
12-03-2014
By proposed changes to Plugin2ClassLoader and JNLPClassLoaders getTrustedCodeSources() methods, I could fix this for html applets, by insuring that security dialogs are not shown till code is loaded (then the main jar would always be loaded first), but due to additional requirements for jnlp applets and applications, JNLPSignedResourceHelper will still show security dialogs before any code is loaded, and therefore before we know which jar is really main jar. I am beginning to agree the only possible fix is to determine the main jar, by mimicking the classloaders and looking for the main or Applet class in each jar before loading anything.
27-02-2014
Thanks for the fix version update. SQE OK to defer the fix to 7u65
17-01-2014
The issues affectes a lot of deployment tests. So, SQE is NOT OK to defer it to 8-pool. SQE OK to defer the fix in one of the jdk7 releases after 7u60.
16-01-2014
Affected tests: FXPermissionTest::testVHNoMFAllpermission FXPermissionTest::testVHNoMFAllpermission_JNLP FXPermissionTest::testVHNoMFMixedcode FXPermissionTest::testVHNoMFMixedcode_JNLP FXPermissionTest::testVHNoMFSandbox FXPermissionTest::testVHNoMFSandbox_JNLP
10-01-2014
request deferral to 8-pool
06-01-2014
There is no good known way to address this, and still maintain rule that only the real main jar is required to have permission attribute. Request we continue to defer this.
03-01-2014
suggested release note text for known problem: If the application is blocked due to failure of the signed main jar to contain the required "Permissions" manifest entry, The security dialog will show first, asking user permission to run the app, before the app is blocked.
24-12-2013
outstanding request to require Permissions in both the "Expected" main jar, and the "Actual" main jar. see wiki at: http://wiki.se.oracle.com/display/JPGC/Main+Jar If this is implemented, the extra security dialog will only show when the expected main jar is different from the actual main jar (unusual case) and where the expected main jar has the permissions manifest entry, but the actual main jar does not.
16-12-2013
Affected tests: FXAppAndPermAttrTest::testBlock_High_MixedMFs_AllPermApplet FXAppAndPermAttrTest::testBlock_High_MixedMFs_AllPermJnlp FXAppAndPermAttrTest::testBlock_High_MixedMFs_SandboxApplet FXAppAndPermAttrTest::testBlock_High_MixedMFs_SandboxJnlp FXAppAndPermAttrTest::testBlock_High_NoMF_AllPermApplet FXAppAndPermAttrTest::testBlock_High_NoMF_AllPermJnlp FXAppAndPermAttrTest::testBlock_High_NoMF_SandboxApplet FXAppAndPermAttrTest::testBlock_High_NoMF_SandboxJnlp FXAppAndPermAttrTest::testBlock_Medium_MixedMFs_AllPermApplet FXAppAndPermAttrTest::testBlock_Medium_MixedMFs_AllPermJnlp FXAppAndPermAttrTest::testBlock_Medium_MixedMFs_SandboxApplet FXAppAndPermAttrTest::testBlock_Medium_MixedMFs_SandboxJnlp FXAppAndPermAttrTest::testBlock_Medium_NoMF_AllPermApplet FXAppAndPermAttrTest::testBlock_Medium_NoMF_AllPermJnlp FXAppAndPermAttrTest::testBlock_Medium_NoMF_SandboxApplet FXAppAndPermAttrTest::testBlock_Medium_NoMF_SandboxJnlp FXAppAndPermAttrTest::testBlock_VeryHigh_MixedMFs_AllPermApplet FXAppAndPermAttrTest::testBlock_VeryHigh_MixedMFs_AllPermJnlp FXAppAndPermAttrTest::testBlock_VeryHigh_MixedMFs_SandboxApplet FXAppAndPermAttrTest::testBlock_VeryHigh_MixedMFs_SandboxJnlp FXAppAndPermAttrTest::testBlock_VeryHigh_NoMF_AllPermApplet FXAppAndPermAttrTest::testBlock_VeryHigh_NoMF_AllPermJnlp FXAppAndPermAttrTest::testBlock_VeryHigh_NoMF_SandboxApplet FXAppAndPermAttrTest::testBlock_VeryHigh_NoMF_SandboxJnlp
06-12-2013
Tow things I need to point out: 1. dozens of SQE test cases FAIL because of this. So this affects pass rate a lot. 2. users will get confused and get bad impression because we first say "it will be blocked in FUTURE JRE", then we block it in CURRENT JRE. At least, we need to release note it.
20-11-2013
SQE is OK to defer this
19-11-2013
closing 8028065 as a dupe of this - same problem in Java Web Start. Any solution should cover both the javaws and plugin cases
18-11-2013
initial attempt to fix only appeared to work due to another bug since fixed. The point remains a problem. In order to correctly identify the "Main Jar" we need to load the class and see what jar it came from. This is done (in plugin) in Plugin2Manager.initAppletExecutionRunnable by calling Plugin2ClassLoader.loadCode(). This results in security dialog, before returning by eventually calling Plugin2ClassLoader.getPermissions() after calling loadCode() we have the class object that we pass on to isAppletTrusted(), which in turn determines what jar contains the main applet class loaded, and calls DeployManifestChecker.verifyMainJar() There is the same problem in Java Web Start. At this point I do not see any way of determining the accurate location of the main jar or class file, other than loading the main class (cls), and using cls.getProtectionDomain().getCodeSource().getLocation() Alternatively I do not see any clean and secure way of postponing the security dialog while the main class is being loaded, till we can verify the Main jar's permission attribute.
14-11-2013
Affected tests: JawsManifestPermissionTest::testBlock_High_NoMF_AllPerm JawsManifestPermissionTest::testBlock_Medium_NoMF_AllPerm JawsManifestPermissionTest::testBlock_Medium_NoMF_Sandbox JawsManifestPermissionTest::testBlock_VH_NoMF_AllPerm
14-11-2013
Affected tests: AppletSignedManifestTest::testBlock_High_MixedMFs_AllPerm AppletSignedManifestTest::testBlock_High_MixedMFs_Sandbox AppletSignedManifestTest::testBlock_High_NoMF_AllPerm AppletSignedManifestTest::testBlock_High_NoMF_AllPerm_JNLP AppletSignedManifestTest::testBlock_High_NoMF_AllPerm_Obj AppletSignedManifestTest::testBlock_High_NoMF_Sandbox AppletSignedManifestTest::testBlock_High_NoMF_Sandbox_JNLP AppletSignedManifestTest::testBlock_High_NoMF_Sandbox_Obj AppletSignedManifestTest::testBlock_VH_MixedMFs_AllPerm AppletSignedManifestTest::testBlock_VH_MixedMFs_Sandbox AppletSignedManifestTest::testBlock_VH_NoMF_AllPerm AppletSignedManifestTest::testBlock_VH_NoMF_AllPerm_JNLP AppletSignedManifestTest::testBlock_VH_NoMF_AllPerm_Obj AppletSignedManifestTest::testBlock_VH_NoMF_Sandbox AppletSignedManifestTest::testBlock_VH_NoMF_Sandbox_JNLP AppletSignedManifestTest::testBlock_VH_NoMF_Sandbox_Obj
14-11-2013
The bug was closed as duplicate of JDK-8028085 which has been resolved (confirmed with 8 nightly #740). However, with #740, the issue in this bug is still reproducible. So reopen it.
14-11-2013
Affected tests: AppletSignedManifestTest::testBlock_Medium_MixedMFs_AllPerm AppletSignedManifestTest::testBlock_Medium_MixedMFs_Sandbox AppletSignedManifestTest::testBlock_Medium_NoMF_AllPerm_JNLP AppletSignedManifestTest::testBlock_Medium_NoMF_AllPerm_Obj AppletSignedManifestTest::testBlock_Medium_NoMF_Sandbox AppletSignedManifestTest::testBlock_Medium_NoMF_Sandbox_JNLP AppletSignedManifestTest::testBlock_Medium_NoMF_Sandbox_Obj AppletSignedManifestTest::testBlock_Medium_NoMF_AllPerm
13-11-2013
closing as a duplicate of 8028033 - the fix for that includes this fix too.
08-11-2013
The fix for 8026422 is proposed for 7u51 without this fix also, when that is put in this problem will occur - so this is relevant to 7u51 as well, just not in any promoted builds. This should be put in 7u51` at same time as 8016422
08-11-2013
webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.8.0/8027821/deploy/
08-11-2013
in order to implement PM requirement that the "real" main jar be the one for which permission manifest is required, we need to load the main class first, then see what jar it is in, this is an ugly side effect of that change, since loading the main class causes this dialog, and it is only after that that we can confirm that the main jar contains the required manifest entry. consider a situation with three jars, main class is actually in the third one. we will load the main class, which will cause each jar to be loaded in order (resulting in the appropriate dialogs) then check that the permission attribute exists in the main jar. Further consideration is necessary to determine how we can handle this.
06-11-2013
Still reproducible with the latest 8 pit bits (#664)
06-11-2013
Affected tests: JS2JavaCACTest::test_JS2SJ_Sandbox_JNLP
05-11-2013
regression_test_src: http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/deployment2/file/6c293dfac7c0/new_framework/tests/plugin/liveconnect/src/JS2JavaCACTest.java
05-11-2013