As of Java 7u45 an applet will display a warning message (even if signed with a trusted cert) if a webpage tries to interact with it via javascript and that page isn't listed in the manifest's Caller-Allowable-Codebase attribute.
Release notes about this change: http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
Oracle blog post about this bug: https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
Attribute description: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/manifest.html#caller_allowable
I have tried just a wildcard (*), but I still get the warning.
Is there a way around this other than listing all codebases it may run at?
The reason this is a problem for me is that this applet runs on many different machines and networks, but always on intranets at various locations. This applet also needs to communicate with javascript because it talks to local USB scales and displays results and interacts with the page.
Applet in question: https://github.com/JaggedJax/CIO_Scale
My findings are the same:
This prevents warnings with Java 7u21 - 7u40:
Manifest-Version: 1.0
Trusted-Library: true
This exclusivly prevents warnings with Java 7u45:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Mixing both won't work in 7u45.
Now what?
Did anyone find a way to allow SIGNED applets with "all-permissions" to run without warnings in both JRE-versions?
What the hell is wrong with oracle?
Removing the Trusted-Library attribute seems to be mandatory to get Caller-Allowable-Codebase working, no more warnings. However, this breaks Java 7 Update 21 - 40 which treated JavaScript code that calls code within a signed applet running with all permissions as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute.
This will be fixed in a future release, according to the oracle blog post:
https://blogs.oracle.com/java-platform-group/entry/7u45_caller_allowable_codebase_and
They recognize the error "Both of these attributes should work together to support the various versions of client installations". But for now, their solution is: "The current work-around would be to favor using Caller-Allowable-Codebase over the old Trusted-Library call. "
I had the same issue. Solution for me was using same parameters in manifest as Oracle used on donwload page in applet for verify java version http://www.java.com/en/download/installed.jsp
Their applet does not popup any warnings.
so solution is:
Manifest-Version: 1.0
Codebase: *
Permissions: all-permissions
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Application-Name: APPNAME
it works on:
1.7.0_17-b02
1.7.0_25-b17
1.7.0_45-b18
from oracle:
Area: Deployment/Plugin
Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.
If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.
http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html
The only solution that I can think of that works with 7u45 and the Trusted-Library versions (7u21, 7u25 and 7u40) is to create two different JARs with different manifests and then detecting the user's version and loading the right one.
The main version served to versions before 7u21 and 7u45 and up will have the new Caller-Allowable-Codebase and no Trusted-Library entry. The second version produced will have Trusted-Library and will be served only to 7u21, 7u25 and 7u40.
Here is an ant macro to create the new jar with the modified manifest:
<macrodef name="addtrustedlibrarytojar">
<attribute name="jarpath" />
<attribute name="newjarpath" />
<sequential>
<echo>Unzipping #{jarpath} to add Trusted-Library</echo>
<mkdir dir="build/temp_trusted_library" />
<unjar src="#{jarpath}" dest="build/temp_trusted_library" />
<echo>Inserting Trusted-Library in manifest</echo>
<replaceregexp match="^" replace="Trusted-Library: true${line.separator}" flags="s">
<fileset dir="build/temp_trusted_library/META-INF" includes="MANIFEST.MF"/>
</replaceregexp>
<echo>Creating #{newjarpath}</echo>
<zip file="#{newjarpath}" basedir="build/temp_trusted_library" />
<echo>Deleting build/temp_trusted_library directory</echo>
<delete dir="build/temp_trusted_library" />
</sequential>
</macrodef>
Call the macro like this for each JAR that needs the change made:
<addtrustedlibrarytojar jarpath="dist/myapplet.jar" newjarpath="dist/myapplet_tl.jar" />
Remember to sign the new JAR. If it was signed already this change will invalidate the signature.
We use the PluginDetect library to detect the version of Java. Just extract PluginDetect_Java_Simple.js and getJavaInfo.jar. This code will get the java version:
<script type="text/javascript" src="js/PluginDetect_Java_Simple.js"></script>
<script type="text/javascript">
var javaVersionDetected = '0';
function javaDetectionDone(pd) {
javaVersionDetected = pd.getVersion("Java");
if (console) console.info('Detected java version: ' + javaVersionDetected);
}
PluginDetect.onDetectionDone("Java", javaDetectionDone, "js/getJavaInfo.jar", null);
</script>
We use javascript to launch our applets so we use this to decide between the standard and trusted-library applets:
if (javaVersionDetected === '1,7,0,21' || javaVersionDetected === '1,7,0,25' || javaVersionDetected === '1,7,0,40') {
if (console) console.debug('Using TL applet');
attribs['archive'] = 'applets/myapplet_tl.jar';
}
else {
if (console) console.debug('Using normal applet');
attribs['archive'] = 'applets/myapplet.jar';
}
I had the same issue, So I remove Trusted-Library=true from my MANIFEST.MF, work Caller-Allowable-Codebase attribute fine.
For update 1.7.0_25 (and probably 21-40), setting the security settings to Medium in the Java Control Panel -> Security tab removes prompting when using the manifest tags for update 1.7.0_45.
This set of attributes allows the applet to load without warnings in Java 7u45:
Application-Name: ...
Main-Class: com...
Sealed: true
Codebase: *
Caller-Allowable-Codebase: *
Permissions: all-permissions
We have tested on the following JVMs:
Java 6u20 (OK, well duh!)
Java 7u21 - must include Trusted-Library to avoid warning
Java 7u25 - must include Trusted-Library to avoid warning
Java 7u40 - must include Trusted-Library to avoid warning
Java 7u45
So the long and short is we have a dilemma; to have no warning on 7u21, 7u25 and 7u40 you must include Trusted-Library:true, and to have no warning on 7u45 you must omit this property.
Thanks Oracle for a Kobayashi Maru - we love you.
I'm finding now that some of my users still get this "mixed signed and unsigned code" warning (due to LiveConnect calls in the web page to the applet) even though I've set Caller-Allowable-Codebase correctly, and the difference between those that get it and those that don't get it is whether they have applet .jar file caching enabled in the client host. Those that allow Java to keep temporary files on the client (i.e., allow applet .jar files to be cached) get the warning, and those that turned caching off (because applet caching has never worked quite right) don't get the warning. Go figure.
Without using Trusted-Library and setting:
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
Doesn't work for me, and i still see the warning.
Update: Tried also with http://... but didn't work either.
Update2: Seems even worse. I didnt update 7u40 (to 7u45) but Java console (full debug) shows the "LiveConnect 1.7.45" text. After that, my Javascript->Java calls are blocked.
Update 3: I noticed my warning shows Application and Publisher = UNKNOWN. Altought i have:
Application-Name: MyApplet
Implementation-Vendor: MyCompany
I tried using JDK7u45 instead of JDK7u5 i was using.
To disable this "Security Warning" popup and other related popups using the Java 8 Update 45 JRE.
Trusted-Library: true
Caller-Allowable-Codebase: *.mycompany.com
Note: security warning popup was not disabled with wildcards * and *.com.
We had this problem too - we were building with 1.4.2, on the theory that clients might not have an updated JRE plugin. Despite putting in the new manifest attributes, we still got the popup warnings in the 1.7_u45 JRE. We rebuilt with 1.6, and the warnings went away.
EDIT: As it turns out, our app was doing something different if the file was in a different directory -- specifically, it wasn't attempting to access the applet signed jar manifests. So the fact that the file was in a different directory was irrelevant. So the below information is not accurate. I've decided to detail the real reason for the warning in a new question: As of Java 7 update 45, one can no longer lookup manifest information without triggering a warning?
Unfortunately, the workaround given by Oracle and others here for getting around the update 45 problem does NOT work if your app needs to access files in a different directory than where the app is being run from.
With my web start app, everything worked fine and dandy with the "Trusted-Library" attribute that needed to be added for 7u21. With 7u45, removing the "Trusted-Library" attribute and adding in all the additional attributes talked about in the other answers will NOT work -- I will get the same warning that you would get if you were running 7u21 without the Trusted-Library attribute (stating the application contains both signed and unsigned code).
It took me FOREVER to figure this out, because for very inexplicable reasons Oracle has decided not to print out ANY indication of what the "unsigned" code is in its console, even when running at maximum tracing (level 5). But basically, our app needs access to a configuration file which can be used by the user to configure application properties (for example, the logging level of our app). This configuration file is a plain old text file. And we store the config file in a directory co-located to where the app runs from: ..\config\app.properties. We access this file as a part of the main jar's init routine. It is here where the warning occurs.
The workaround here? Move app.properties into the same directory where the app is running from (and change the reference in the jar to just "app.properties"). Voila, it works -- no more warnings (as long as using the aforementioned codebase attributes). What the hell Oracle???
Unfortunately, because our app allows customized config files on a per-user basis, it is not as simple for us to just put the config file in the app's startup directory -- since that is NOT customized on a per-user basis, we would only be able to allow one user per machine to use the app simultaneously.
I've been looking over Java's manifest documentation to see if there is some way I can make the config file directory "safe" such that loading up of this file doesn't cause the warning. The only thing I can think of is either being able to use the Class-Path attribute or a combination of the Extension attributes (http://docs.oracle.com/javase/7/docs/technotes/guides/plugin/developer_guide/extensions.html), however these all seem designed around the purpose of jars, not just regular files...
Any ideas? And since Oracle intends to fix the Trusted-Library issue anyway, is coming up with a (potentially) grandiose workaround-solution around this even worth the effort? Grrr....
I found some strange thing with MANIFEST.MF file in scope of last Java security issue with new attribute "Caller-Allowable-Codebase".
I had some issues, why this new attribute wasn't helpful for me and started investigation
(Attention!: it may be related only to my local computer configuration - because I had never seen such troubles over stackoverlow).
Manifest file had been upgraded according to new security feature:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
and *.jar was build, but without signing.
So, then I unpacked my *.jar file and looked in folder META-INF in MANIFEST.MF, where source manifest.mf should be generated.
And I was embarrassed by absence of last line, it looked this:
Manifest-Version: 1.0
Application-Library-Allowable-Codebase: *
I tested this behavior several times and found out, that last line always was exchanged to the whitespace.
So, if it will be helpfull for someone, just append in the end of MANIFEST.MF file some unmeaningful attribute, like Codebase: *, which will be cutted during *.jar build.
if you make a Manifest patch file remember to live an empty line in the end, otherwise it won´t work.
For example you can make a patch like:
Permissions: all-permissions
Codebase: *
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
But you need to add an empty line (in the example 5 lines instead of four!)
And then add it to the manifest:
jar uvfm jarName.jar permissions.txt
Related
IBM Cognos generates EAR file which includes a lot of JARs in /WEB-INF/lib/
Of those JARs, a few (namely, idvisualizations_helpers.jar and some others) in their /META-INF/MANIFEST.MF contain the following:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: jvmwi3260sr10-20111207_96808 (IBM Corporation)
Main-Class: ${project.main.class}
Class-Path: ${relative.classpath}
Is this valid? I mean, who will be responsible for expanding those {} placeholders? To me this does not even make any sense: if software executing the JAR knows its main class, there is no reason to mention it in Manifest.
I can only think of two explanations. First, this is a plain and simple bug, a failure to substitute those placeholders when making a JAR. Second, such a notation is valid and assumes that the JVM using that JAR will provide values for those placeholders (but I don't believe in this, as specifying different value for each such JAR would be too inconvenient).
Someone please explain what does that mean. More practical part of the problem is that on Websphere Liberty 8.5.5 an error is produced because of "${relative.classpath}" not being a valid URI. I wonder why that does not happen on another environment running full Websphere (though the Cognos configuration there differs from mine).
No, having properties in your final manifest that is used by the Java JVM is not valid based on the Java specifications. When I say "final" I mean you might have properties in your manifest as part of your source code which are then filtered out during the build and replaced with the values of those properties. This is perfectly fine. Another possibility is that there may some post-build processing that replaces those properties with the correct values.
You said:
...on Websphere Liberty 8.5.5 an error is produced because of "${relative.classpath}" not being a valid URI. I wonder why that does not happen on another environment running full Websphere (though the Cognos configuration there differs from mine).
I'm not quite clear on what you meant with that last part about the Cognos configuration differing from yours, but it sounds like you're saying that the manifest you showed in your question is working on one platform but not on another. I would imagine that either one platform is performing post processing or the two platforms have different deployed code somehow. I suggest going back and confirming that you have the exact same manifest in both platforms and debug your build process to try to find where those variables' values are obtained and when.
Please see this link for more information about the manifest file.
I have some problems with opening a SAN switch in Webtools (Java version 8 Update 31).
The first problem was a failed to validate certificate
This was fixed by following the instructions on this site
However, then I got following error:
Which was solved by adding these 3 entries to the site to the exception site list (the last one is the only one necessary I think)
http://i.p.address/*
http://i.p.address/switchExplorer.html
http://i.p.address/
But now I get following error:
your security settings have blocked an application from running due to missing a “permissions” manifest attribute in the main jar web tools
The solution seems to be adding the URL to the exceptions but I have already done that in the previous step..
Open the "Mission Control Panel" of java.
If you cannot find it, have a look in the bin folder of your jdk installation, the executable should be called jcontrol.
Run it, open tab "Security", Button "Edit Site List" and add your URL to the Exception Site List. I.e. https://10.0.0.1 is all you need.
Use oracle java if you use linux and somehow miss jcontrol from the openjdk package.
Afterwards you should be able to start the .jnlp (or however you want to start the applet) of your desire.
My applet application is blocked with java security.
I tried to adding the site to trusted sites , but it didn't worked
The Medium security were removed from Java 8 Update 45
I would like to know how to remove the security?
Also I wondering what makes my application unsafe and how to make it safe?
Be certain that you have manifest entries such as this sample (adjust for your unique circumstances):
Permissions: all-permissions
Codebase: https://app.mycompany.com/applicationfolder
Application-Name: HelloWorld
You may apply the manifest through something along the lines of:
"%JDK_HOME%\bin\jar.exe" ufm ..\dist\application.jar manifest.txt
My JNLP still works fine after our switch from Java 6 to Java 7, but it now throws a whole series of errors like this:
Missing Application-Name: manifest attribute for: http://blah.com/app.jar
Missing Permissions manifest attribute for: http://blah.com/app.jar
Missing Codebase manifest attribute for: http://blah.com/app.jar
It repeats several times for our main jar and a couple times for one of our library jars. However, it does not occur at all for the bulk of our library jars. JaNeLa lists some optimization opportunities (by changing some defaults), but none of those appear to be related, and no actual errors are found.
So far searching the web has left me empty handed on how to make the JNLP file format into something that Java 7 finds worthy. :-)
See Missing Codebase manifest attribute for:xxx.jar for an explanation for Permissions and Codebase. If you use ant, you can use the following to add the entries to the manifest:
<manifest file="${source}/META-INF/MANIFEST.MF" mode="update">
<attribute name="Permissions" value="all-permissions"/>
<attribute name="Codebase" value="${jnlp.codebase}"/>
<attribute name="Application-Name" value="${app.name}"/>
</manifest>
Java 7 update 45 broke my Web Start SWT application might also have some interesting information
This issue affects both JNLP and applets. The jar files are required to have a permission attribute in the manifest file. I believe the other errors are less critical. The latest JRE shows end users a warning message stating that starting January, 2014 the latest JRE will refuse to run any applet or JNLP jar files with a missing Permissions attribute.
See Java SE7 technotes on manifest.
The Java tutorial has a section on modifying the manifest file but doing this with ant as suggested by #mth sounds simpler.
I could make a self signed java web start application work with a workaround.
Even though I can see warnings in the console, I get no more warnings.
All I needed was:
adding the "Permissions: all-permissions" attribute in the manifest.
Adding the following tag in the jnlp file:
<security>
<all-permissions/>
</security>
signing my jars with my own keystore
importing my own certificate in the Java Control Panel (on Windows).
If you are using maven this can be done by simply adding something like this in your plugin configuration:
<updateManifestEntries>
<Permissions>all-permissions</Permissions>
<Codebase>*</Codebase>
</updateManifestEntries>
Taken from the plugin site here
I am using Mac 10.7 running Java 1.7.0_21. I am trying to run a Java applet application that is signed and towards the end of the application I get a mixed mode security popup saying "Block potentially unsafe components from being run?". All the jars that I am using are signed.
I am able to run the same applet application on Mac 10.6 running Java 6 and I don't get the mixed mode warning. I am also able to run the application on windows without the mixed mode warning coming up.
Why do I get this keep getting this error when all my jars are signed?
I googled mixed mode warning and found this link.
http://docs.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html#manifest
and after reading this link, I am a little confused. According to this link it looks like I need to have either "Trusted-Only" or "Trusted-Library" attribute mentioned inside my manifest file. I looked at my manifest file and they don't have these attributes so should I put them in or just the fact that the jars is signed should have been enough.
Can someone please help me understand why I am getting this error even when everything is signed?
Update 21 of Java 7 is a strong security update that brings a certain number of breaking changes.
You should have a look to its release notes, there are two paragraphs and two known issues related to signed jars.
Your problem consists in this one:
Area: deploy/plugin
Synopsis: Security popup while closing application
Starting in JDK 7u21, JavaScript code that calls code within a signed applet running with all permissions is treated as mixed code and warning dialogs are raised if the signed JAR files are not tagged with the Trusted-Library=true attribute. See Mixing Code With Permissions and Code Without Permissions(doc link)'.
For a signed applet running with all permissions to JavaScript call, no security dialog (with mixed code warning) should pop up. However mixed code warning is being shown in some scenarios.
The good news: there is a workaround:
As a workaround, if the applet jar is running with all-permissions and uses "Trusted-library:true" attribute as manifest entry, the mixed code warning will not popup.
The best fix is using the Trusted-Library=true, however, if you cannot get this to work for some reason you can also change how the computer handles mixed security applets.
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html
Create the follow file on the user's workstation. C:\Windows\Sun\Java\Deployment\deployment.properties
In the file add the following line:
deployment.security.mixcode="HIDE_RUN"
This will tell Java to hide the security warning and run the applet whenever there's a mixed code condition. Also, on the release notes it says:
As of JDK 7u21, JavaScript code that calls code within a privileged
applet is treated as mixed code and warning dialogs are raised if the
signed JAR files are not tagged with the Trusted-Library attribute.
For more information, see Mixing Privileged Code and Sandbox Code
documentation.
The JDK 7u21 release enables users to make more informed decisions
before running Rich Internet Applications (RIAs) by prompting users
for permissions before an RIA is run. These permission dialogs include
information on the certificate used to sign the application, the
location of the application, and the level of access that the
application requests. For more information, see User Acceptance of
RIAs.
FYI, JRE 6u19 if an applet contains both privileged components and sandbox components, warning dialogs are shown.
I also have an applet that generated this security warning starting with JRE 1.7.0_21.
Here is what I have learned. The "Trusted-Only: true" you would put in your applet manifest if you do not want the user to be asked if he will allow the call to another signed jar. The call will be blocked without the security warning. The "Trusted-Library: true" you add to the jar that you are calling. If this is in the jar's manifest and the jar is signed then when your applet calls it there will be no security warning and the call will not be blocked.
My applet uses the swing-layout-1.0.4.jar. To solve the problem I had to add the "Trusted-Library: true" to the swing-layout-1.0.4.jar. You should be able to do this by using the jar.exe application in the JDK.
jar vcmf swing-layout-1.0.4a.jar MyManifest.mf swing-layout-1.0.4.jar
MyManifest.mf is a text file containing "Trusted-Library: true". The space between the : and true is important and you must have a carriage return at the end of the line.
For some reason I could not get this to work so I rebuilt swing-layout using netbeans. The sources for swing-layout-1.0.4 are part of the netbeans install (under platform). I unzipped it opened it as a project. Under files I changed the manifest file to have the magic line (again it is important to have the space after the : and a blank line at the end of the manifest file) and hit the build. I then signed the jar and no more security warning.
I hope this helps or at least points you in the right direction
Thank you all for your replies. I tried adding Trusted-Library=true on a small sample and it seems to work. So now I will be trying to trying update the manifest file of all my jars. And since we use ant I will doing the following
<jar update="true" jarfile="${deploy.dir}/javaApp.jar">
<manifest>
<attribute name="Trusted-Library" value="true" />
</manifest>
</jar>
to update the manifest files.