Created attachment 534691 [details] Output from: javaws ViewImage.aspx.jnlp Description of problem: See attached file jnlp.txt Version-Release number of selected component (if applicable): How reproducible: every time Steps to Reproduce: 1. javaws ViewImage.aspx.jnlp 2. 3. Actual results: output as in jnlp.txt Expected results: Display image of old handwritten document Additional info: Works on Windows 7 with Sun's java
Created attachment 534692 [details] aspx.jnlp file which triggers the bug Am adding the example file which triggers the bug. The file is one of millions of similar files that are accessible on the Internet. They are scanned pages of all Danes from early 1700 till today containing information like birthday, marriage, death etc.
As the error says, the jar files contain unsigned content, but the application wants full permissions. I can confirm that at least http://www.sa.dk/LAView/commons-discovery-0.2.jar contains file(s) that are unsigned. We can not grant permissions to such jar files. If we did, then it becomes possible for someone to add their own code/metadata/whatever to this jar, and have it execute with full privileges instead of a sandbox. It may turn out that the additional files have no security implications, but it could just as well be malicious code, and compromise the security of your system. The only correct fix, IMHO, is for the folks who host this jar (http://www.sa.dk/LAView) to make sure all files in their jars are properly signed. The fact that the Sun/Oracle JDK works with this file is a bug in their JDK.
Created attachment 535787 [details] Sun/Oracle's dialog box.
You could do like Sun/Oracle, ask the user if he accepts the risk. See attached file.
No, that dialog shows something slightly different. It asks if you trust the entity who has signed the jar. You can normally click the 'more information' button in that dialog to get additional details about who the entity is. The javaws that ships in fedora does that too. However, this is different from the case where unsigned files are present. In such cases, we refuse to run the program. The Sun/Oracle JRE does this exact thing too, actually. It refuses to run if unsigned entries are present - unless the unsigned files under META-INF/ in which case the program runs. I have talked to folks who deal more with software security and they agree that this is not a completely safe thing to do, so we dont emulate this 'bug'.
Upstream has made an explicit decision about this. Please see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=722 and post any concerns or suggestions there. F14 has been EOL'ed and wont be getting a fix (even if upstream creates one). I am closing this bug as WONTFIX.