As for the Java 7 45 update, can you no longer search for manifest information without triggering a warning?

Question

Unfortunately, the workaround given by Oracle and others here ( Java applet manifest - Allow all Caller-Allowable-Codebase ) to solve the problem with update 7, DO NOT work if your application needs to access its loaded manifest of signed ATMs. In my case, our application does this to register the relevant manifest information.

Everything worked fine with my web starter application and a dandy with the “Trusted-Library” attribute, which must be added for 7u21. With 7u45, deleting the "Trusted-Library" attribute and adding to all the additional attributes that were mentioned in other workarounds will NOT work - I will get the same warning that you get if you use 7u21 without the Trusted-Library attribute (stating that the application contains both signed and unsigned code):

I tried almost every manifest / JNLP replacement - nothing cuts the mustard.

I found that basically when we load one of the jar applet manifest (and not the JRE jar) and call hasMoreElements, additional security checks occur that trigger a warning:

public List<String> getManifests() { ... Enumeration<URL> urls = getClass().getClassLoader().getResources("META-INF/MANIFEST.MF"); while (urls.hasMoreElements()) { .... a bunch of loop stuff // at the end of the loop... System.out.println("Checkpoint SGMLOOP8."); System.out.println("Breaking...."); //break; <<<<<<---- if the next jar is one of our signed jars, the next line will trigger the warning. If instead we choose to break, the app works perfectly with no warning. System.out.println("urls.hasMoreElements(): " + (urls.hasMoreElements() ? "true" : "false")); <<<<<<-------- will evaluate to false if user clicks Block on the warning, otherwise will evaluate to true when our signed jars are next System.out.println("Checkpoint SGMLOOP9."); } ... } 

This is what prints on the Java console with maximum tracing:

 Checkpoint SGMLOOP8. Breaking.... <<<<---- console output pauses here until user answers warning security: resource name "META-INF/MANIFEST.MF" in http://<path_to_jar> : java.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://<path_to_jar> (message repeats for all our signed jars) urls.hasMoreElements(): false <<<<---- false because user clicked blocked, otherwise true when user clicks don't block Checkpoint SGMLOOP9. 

It took me FOREVER to figure this out, because for some reason, when a signed manifest that passes security checks earlier in the startup process and then gets access and complains, I naturally complain about the manifest, but rather about the resources, referenced by the manifest. Go figure!

By looking into the Java source code, I can understand why a warning might occur (hasMoreElements leads to more security checks):

 // getResources is called in my code above java.lang.ClassLoader public Enumeration<URL> getResources(String name) throws IOException { Enumeration[] tmp = new Enumeration[2]; if (parent != null) { tmp[0] = parent.getResources(name); } else { tmp[0] = getBootstrapResources(name); } tmp[1] = findResources(name); <<<<------ This returns a new Enumeration<URL> object which has its own "hasMoreElments()" method overwritten – see below code return new CompoundEnumeration<>(tmp); } java.net.URLClassLoader public Enumeration<URL> findResources(final String name) throws IOException { final Enumeration<URL> e = ucp.findResources(name, true); return new Enumeration<URL>() { private URL url = null; private boolean next() { if (url != null) { return true; } do { URL u = AccessController.doPrivileged( <<-- Security context could block this new PrivilegedAction<URL>() { public URL run() { if (!e.hasMoreElements()) return null; return e.nextElement(); } }, acc); if (u == null) break; url = ucp.checkURL(u); <<-- Security checks done in here } while (url == null); return url != null; } public URL nextElement() { if (!next()) { throw new NoSuchElementException(); } URL u = url; url = null; return u; } public boolean hasMoreElements() { return next(); } }; } 

Yes, manifests are correctly signed! Yes, manifests have corresponding attributes! . In fact, this is verified by the fact that the jars load just fine and execute if we are not trying to directly access their manifest! However, to appease your concerns, here are the relevant attributes of the manifest (I tried MANY add / subtract the following attributes):

 Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 24.45-b08 (Oracle Corporation) Application-Name: AppName Codebase: * Permissions: all-permissions Application-Library-Allowable-Codebase: * Caller-Allowable-Codebase: * Trusted-Only: false Class-Path: jar1.jar jar2.jar jar3.jar Specification-Title: AppName Specification-Version: 1.0 Specification-Vendor: CompanyName Implementation-Title: AppName Implementation-Version: 1.0 Implementation-Vendor: CompanyName 

Question: Should a warning appear when we try to access the manifest? Be that as it may, we either have to choose to get users to see a warning every time, or we need to delete our log of our signed jar manifest information. This seems to be a bad choice, especially since this manifest information is very useful for debugging problems, as this is the only way to verify that the end user is working with the correct version of the application (except for direct physical verification in place). This is especially true for our applet, since banks can be cached on client systems (together with the appropriate JavaScript to access the applet), that is, they can very easily launch incorrect banks after updates / downgrades, etc. Not having this information in our magazines can lead to big headaches in the future.

Any ideas? This is especially frustrating, since Oracle intends to fix the problem with the trusted library anyway, so all this investigation work in this case can be nothing more than a waste of my weekend. Hmm ...

EDIT: One of the observations that I had was that the first bank that ran into a security exception was actually dependent on another bank in my application. I thought: "Maybe the manifest of the dependent box should be read first?" Therefore, I forced the boot order so that independent banks were loaded first. Final result? I saw that the jar independent jar now threw the security exception first ... and there is still a warning.

Answer 1

This question needs to be updated to say that since Java 7 Update 55 this problem has been protested, since again you can add the manifest attributes "Trusted-Library" and "Caller-Allowable-Codebase" at the same time. Using both of these attributes in the manifest will not trigger a warning.

Answer 2

I get this problem with applets and find that I get a warning about hasMoreElements in my own .jar files for applets (and not in java Java systems that return for the first time through the loop), and only when the Java Control Panel is turned on caching .jar files.

I can’t get all my clients to turn off caching of .jar files, but those that are really happy right now, as the mixed code warning doesn’t appear for them. This is not an answer, at best it is a workaround.