Warning on Permissions attribute when running an applet with JRE 7u45

Question

I\'ve just upgraded JRE to 7u45, and my applet receives a warning message on start-up, saying \" This application will be blocked in a future Java security update because th

Answer 1

I don't know that my original answer (deleted) was wrong. The Permissions attribute in the manifest should not be ignored in a local applet, so, it's a bug.

There are similar known issues described in the 7u45 release notes. This must be related.

As to the original question: Codebase: * ?

Codebase: localhost

It works for http://localhost and it does not contradict file://localhost/C:/folder, which (on Windows) is the correct JNLP codebase syntax. The Codebase attribute in the manifest allows multiple entries. Adding localhost surely will have no adverse effects.

Update:

Manifest-Version: 1.0
Implementation-Title: MyApplet
Implementation-Version: applet build
Built-By: bnicer
Application-Name: Slide Show
Created-By: 1.7.0_45-b18 (Oracle Corporation)
Caller-Allowable-Codebase: *
Implementation-Vendor: MyFirm
Ant-Version: Apache Ant 1.9.2
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Built-On: 8 November, 2013 @ 13:40:10 GMT
Trusted-Only: true
Permissions: all-permissions
Main-Class: jtss
Codebase: www.mydomain.co.uk localhost 127.0.0.1 192.168.2.2

I believe that running an applet offline under 7u45 will make problems no matter what you put in a manifest, and that is very unfortunate.

As far as I can tell the older method of adding a .java.policy file to the local directory is just as pointless, and that too is unfortunate.

More Info:

(Concerning the bug?)

If the applet is signed, you have the option to import the public certificate (.csr, .p12, .cer) in the Java Control Panel: Security > Manage Certificates > User > Signer CA. Importing the certificate in the past ensured: A) the applet publisher was known. B) the security popup before running the applet in the browser would be removed.

• Web Start applications, ditto.

The difference is that now (7u45): A) the publisher is known. B) you receive a "... manifest does not contain the Permissions attribute" warning.

• Local applets only.

After the warning, it has been my experience, that the applet won't run.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
    at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.access$100(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
    at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    ... 14 more
Caused by: java.lang.NullPointerException
    at sun.plugin2.applet.Plugin2ClassLoader.loadAllowedCodebases(Unknown Source)
    at sun.plugin2.applet.Plugin2ClassLoader.getPermissions(Unknown Source)
    at sun.plugin2.applet.Applet2ClassLoader.getPermissions(Unknown Source)
    at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
    at java.security.SecureClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    ... 18 more

A work-around, but by no means a fix, is to delete the certificate from the Signer CA store. On deleting the certificate (in desperation, as a last resort) the signed, local applet runs as follows: A) UNKNOWN Publisher, etc. B) you get a security dialog, and the missing Permissions attribute warning.

• None of the above applies to applets online.

Feel free to comment.

Answer 2

In your Java control panel, change the security level to Very High, that way it will block the applet from running because it is missing the required Permissions attribute. Run your application, an exception will be thrown which will tell you which jar is missing the attribute.

I was under the impression that adding the Permissions attribute to the main jar of the applet would be sufficient but I just found out that even an ancillary jar can cause the issue. I will now add the Permissions attribute to all my jars.

Hope this helps someone.

Answer 3

From New security requirements for RIAs in 7u51 (January 2014) in the "Java Platform Group, Product Management blog":

As of 7u51, (January 14, 2014), your RIAs must be updated. [...]

RIAs must contain two things:

1. Code signatures from a trusted authority. [...]

So it would appear that using a self-signed certificate is the problem here.

I think it's clear that a self-signed certificate is not much use as an introduction for an end-user.

Answer 4

In 1.7.0_u45 you will probably need to have both the Permissions and Caller-Allowable-Codebase attributes set:

Caller-Allowable-Codebase: * localhost 127.0.0.1
Permissions: all-permissions

see this diagram which explains the security popups

I'm setting my manifest attributes like this:

Application-Name: MyAppName
Implementation-version: %VERSION% 
Permissions: all-permissions
Caller-Allowable-Codebase: * localhost 127.0.0.1
Application-Library-Allowable-Codebase: *

Answer 5

Run the java uninstall applet to remove old versions of java. http://java.com/en/download/uninstallapplet.jsp

Answer 6

Add the base url to the list of secure sites (excepted from checks) in the Java control panel's security tab, that made my vpn launch again: