JDK-8027862 : Regression: Security warning is shown instead of Application Blocked dialog if permissions attribute is missing
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u51,8
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2013-11-05
  • Updated: 2013-11-18
  • Resolved: 2013-11-11
Related Reports
Duplicate :  
JDK-8027821 - For signed jars without manifest "Permissions", there is still security warning dialog before Application Error (Or blocked) Dialog.
Description
Build Tested: 8-b255_2013-11-05-0301_664
In jdk8 we are going to block all applications/applets at levels if permissions attribute is missing from the signed jar. We used to show application blocked dialog against all such scenarios.  But now we started to show the security warning dialog (with yellow warning) instead of application blocked dialog. In case user selects to run then we end up throwing security exception 
Steps to reproduce 
1) Make sure that exception list if not defined and SLIDER level is set to HIGH(default level) or VERY HIGH
2) Import following certificate into trusted signer CA store 
http://sqeweb.us.oracle.com/deployment2/jitu/plug-bug/DRS/new626.p12 
3) Try to load following applet
http://sqeweb.us.oracle.com/deployment2/jitu/plug-bug/ocsp/new/AppletFullJavaVersion.html
If instead of application blocked dialog , security warning dialog is seen then bug is reproduced
Comments
problem is fixed as JDK-8028033 closing as a duplicate
11-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
Bug is filed against nightly build #664
05-11-2013
this sounds like cause is mis-merge we fixed yesterday in todays pit build #664 - can you retry with this pit build ?
05-11-2013
This is also a regression as compare to 7u45 where we used to show Application Blocked dialog against all such scenarios at VERY HIGH settings. But this is not true anymore as explained above
05-11-2013