How to avoid mixed code warning from third party lib loading binary resources?

Question

I'm working on an enormous applet, loads over 100 jars, 50 of which are third-party. All of them are signed and trusted.

Unfortunately, one, openmap, loads binary files (shape and layer files). I cannot sign these files (AFAIK), because they aren't jars, don't have manifests, etc.

Since the jar loads binary files, I get the mixed code warning when running. The only thing I've figured out to avoid this is to mark EVERY .jar as "Trusted-Library: true". Changing the manifest on all the .jars means that all the .jars have to be re-signed, which is a political problem.

I know the dialog can be disabled in the java control panel. I'm looking for another workaround. Naively, I would like to be able to somehow mark openmap or my jar that uses it to be trusted (or whatever it takes) to load those files without the warning. I tried making openmap a trusted-library, that doesn't eliminate the error. If I try making my jar that uses openmap a trusted library, then I run into issues because my jar depends on yet other jars and the class definitions in my jar can't be loaded because those dependent classes are in another classloader.

Edit:
This appears to trigger the dialog (Clicked "Yes, block potentially unsafe" to get this logging statement)

security: resource name "http://localhost:8080/maps/politicalWorld/vmap_political_world/vmap_area_thin.shp" in http://localhost:8080/app/client-lib/ : java.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost:8080/app/client-lib/

Answer 1

If you bung the files into jars, sign and load them as resource, that should be fine. You may have problems loading them through a URL that is in the codebase (as they become impossible to distinguish from part of the applet). However, if you move them out of the codebase, remember that they may be replaced by something malicious, so they cannot be trusted.

I suggest not adding Trusted-Library: true as it is vanishingly unlikely that that will be safe. Not that any of the code is malicious, but that it wont have been designed to be safely used as a library.

Also disabling the mixed-code warnings opens the client machine up to attack that the mixed-code warnings are supposed to mitigate.