I would just also like to confirm this issue. We deploy our application with versioned JAR files (version information in the file name) and use the 'version' attribute on the <jar> element in the JNLP file. Using this method, JWS under 7_45 incorrectly reports the missing Permissions attribute. If I simply remove the version information from the JAR file name and remove the 'version' attribute in the JNLP, then JWS launches the application with no message regarding the Permissions attribute. This seems to be a clear bug and is easily reproducable. I have also submitted a bug report, but have not heard back. For anyone interested, you may want to post comments to the following blog: https://blogs.oracle.com/java-platform-group/entry/updated_security_baseline_7u45_impacts as that might get visibility of this issue to the development team faster.
Just thought that I would share a potential work around to this issue. In re-reading the release notes of 7u45 and the known issues, it states that you may notice the yellow warning if versioning is defined for the main JAR file. Got me to thinking that the versioning might only be a problem on the main JAR file and not on other JAR files defined in the JNLP. After some basic testing, it appears that this does work. So, what we've done, is split our main JAR file into two JARs. The first JAR contains only one class, which just calls a method in another class to launch the application. The second JAR file contains all the application files and can use versioning just fine. Still some more testing to make sure this will work for production, but so far seems like it will work.
My hope is that Oracle will fix this egregious bug in short order, although I have yet to see it appear at https://bugs.openjdk.java.net having filed a report last week. I don't think these forums get much if any attention from Oracle, sadly. Paid support seems the only viable way to go to escalate -- which is unpalatable for blatant JRE bugs.
I am hesitant to apply the suggested workaround, particularly since component extension JNLPs aren't validated like the main application JNLP (see https://forums.oracle.com/thread/2586582). Also, splitting the application apart as suggested increases the overhead for loading the applet.
Bottom-line: these new security features for applets are half-baked and chock full of showstopper bugs. Oracle should be embarrassed this went out the door this way.
Yes, I agree that Oracle should fix this bug. Unfortunately, as the bug is listed as a known issue on the release notes for 7_45, I am not confident that it will be fixed prior to the January deadline. With customers complaining about perceived security vulnerabilities with our application, we simply cannot wait for Oracle to fix it. While I understand your concerns on overhead for loading the application, I do think it can be minimized. Our new method is more simple that what I suggested earlier (that's what I get for working on this past midnight). What we've done is simply publish a new JAR file. The JAR file contains one class, and all that class does is call the main() method of our application. We updated the JNLP file to change the main class, add our new JAR file, and explicitly set our JAR file as the main JAR file. There is no need to a component extension JNLP, we just added the new JAR file to the <resources> tag in the existing JNLP. No changes to the existing application or the JAR files, other that the manifest attributes. Those files still use versioning exactly as they did before.
Since the new JAR file only contains one class file, there really is no advantage to using the version attribute (as I believe that class files are the smallest granularity expressed by the JarDiff process performed by JnlpDownloadServlet). I share your frustration that 7_45 was released with this issue, among others, but we need to support our customers, and this is a work-around that will work and that we can deploy to our customers immediately. Hopefully others will find this information useful.
main() method of your application? I'm a little confused -- are we not talking about JNLP deployed applets here, where the methods of interest are Init(), start(), etc., i.e., there is no main()? I have a "main-class" attribute in my "applet-desc" tag that points to the appropriate class, and the jar resource containing that class has the "version" attribute and the "main" attribute set to false (again, there is no "main()" method, since this is an applet).
Also, version download support I think is more than just for supporting JAR diffs, it's also to make it clearly visible to the end user through the Java Control Panel which version they have and to enable the server to easily give new versions to clients without forcing the clients to clear the cache, etc.
Oh, sorry. I'm working with a desktop application deployed via Web Start, not an applet, so my app has a main() method. Maybe you could create a new main-class that simply wraps the init(), start(), etc calls to your current main-class? Not too familiar with applets, but I would think the concept still applies. And yes, the version support is great for all those things, however I anticipate that the code in the new main class will never change, since it simply wraps a call to main(). We'll need to resign it when our certificate expires, but that's about it.
I am thinking about trying your idea as well, but yes, in my case I need to stick with the applet life cycle model.
Another possible complication is that we use a signed JNLP/APPLICATION_TEMPLATE.JNLP which I'm pretty sure has to be in the main JAR to be effective. But putting it up in the JAR that we expect to never change to avoid this stupid bug sort of defeats the point.
Finally, just for simple code maintainability and sanity, I'm not sure how much sense it makes to go through major contortions to avoid a clear JRE bug (not that I haven't done so in many other cases already... ;->)
Oh, and I forgot to say that I should think resigning the fake main will never be necessary presuming you are using a time signature (jarsigner -tsa). But if not, forcing a new version of the fake main to your clients without manual intervention could prove troublesome since it's not versioned. Hopefully, the standard HTTP cache-expiration mechanisms would work, but who knows?
I experimented with a variant of your suggestion, and, yes, I can get it to work without the spurious Permissions warning by making the main JAR not versioned -- and have it contain a class that simply extends the actual applet class in the version JAR. Unfortunately, I also have to move my signed JNLP-INF/APPLICATION_TEMPLATE.JNLP into this outer JAR in order for the Java Plugin to see and process it. And because I'm putting it in a jar I expect to rarely if ever change, I have to use far more wildcards than I'd like, and for "property" tags in the template I can't use wildcards due to another bug https://forums.oracle.com/message/11244286. Oracle gets us coming and going on this one.
I have the same problem, and so I'm pretty happy I found this thread. I tried Ryan's workaround, and sure enough it worked. But during my implementation, I found something pretty interesting. I accidentally forgot to change the main-class attribute, but the fix worked anyway. Yes that's right, the additional jar is not being directly referred to by any other code (since it was intended to be a wrapper around Main), but the inclusion of this jar caused the warning about the missing Permissions attribute to go away. To be precise: the extra jar has the Permissions attribute, is signed, has a single class, and does not include the version attribute. Hope that helps!
The Java Plugin is using either the "main-class" attribute on the "application-desc" or "applet-desc" tags to determine which JAR is the main one for purposes of where to search for the JNLP template, JNLP-INF/APPLICATON_TEMPLATE.JNLP. You are correct that the signed unversioned JAR appearing first in the resource list can bypass the Permissions attribute missing bug, regardless of whether the resource is used or not (which I agree is interesting) -- but there appears to be no way to avoid of the issues I mentioned in my post of Nov 7. We have chosen to live with false alarm Permissions warning in hopes that Oracle will fix it promptly -- although I still don't see it on https://bugs.openjdk.java.net. :-(
The template JNLP can *only* be found in the same JAR from which the main class comes from -- which I find quite annoying. (As an aside, there also appears to be no mechanism to specify a signed JNLP for component extensions.)
We implemented the change and it fixed the issue when JRE warn the application run with the unrestricted access. Thanks Ryan.
We are still seeing the missing Permissions attribute warning when establish SSL connection as we using the self-signed cert.(Same as Jim)
Did anybody see any articals/forum threads talking about the self-signed cert warning issue?
This IBM article seems to suggest that the yellow box warning about missing permissions is shown in error when using a self signed cert to establish an SSL connection