Bug 675271
Summary: | javaws no longer will run app that previously ran fine | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | long | ||||||
Component: | icedtea-web | Assignee: | Omair Majid <omajid> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | rawhide | CC: | acathrow, ahughes, bloch, colin.panisset, davidkwood, dbhole, d.bz-redhat, don-redhat-z6y, gianluca.cecchi, hany, jvanek, knoe3301, langel, lkundrak, mbooth, mjw, mmatejov, omajid, orion, smooge, tengel, tobias.pal, watts | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2012-08-24 20:12:52 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
long
2011-02-04 18:36:20 UTC
Can you post the jar by any chance? From the looks of it, you have a jar where not all the entries are allowed. Such jars are no longer allowed as they leave the door open for potential security issues. I can't post it publicly if you have another way for me to get it to you (about 1 MB). Does the verbose jarsigner output I've attached help at all? Created attachment 477461 [details]
jarsigner -verify -verbose sinetfactory.jar
Can you grab the packages from http://omajid.fedorapeople.org/java-1.6.0-openjdk/ and check if they fix the problem? yes, now the applet and app both run again This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping still an issue with java-1.6.0-openjdk-1.6.0.0-57.1.10.1.fc15.x86_64 *** Bug 738811 has been marked as a duplicate of this bug. *** The "fix" used to produce packages noted in comment 4 was discussed upstream: http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/12020 (oops, I added this to Bug 738811 - I guess I should say it here too. Although the context may be important.) I was wondering whether replacing that jar with a more recent version would help. I just tried the latest version (5.1.17) and I seem to still get the same thing. Can you verify that the new jar has the same problem? I now realize that this particular url, using ids driver, does not even need the mysql driver. When I remove the jar from the list it works! However, I would then expect the same problem to affect the other url which does use the mysql driver. And yet that one gets much further -- why is that? BTW, Doesn't this seem the sort of thing that mysql (now oracle!) really should fix? Or is it possible that all other java implementation accept unsigned index files? Finally The fix above seems to require changing my java distribution, which means that the applet still would not work for others using the standard dist, right? I was hoping that I could at least arrange to sign the unsigned entry and then have that new jar work for everyone. Created attachment 533940 [details] .JAR file which causes the problem reported in this issue too While trying to use following application: http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/rdf-gravity.jnlp same problem occured to me: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:659) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:436) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:830) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:251) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:171) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:283) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:650) ... 2 more Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:251) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:171) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:283) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:650) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:436) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:830) System details: $ uname -r 2.6.40.6-0.fc15.x86_64 $ java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-60.1.10.4.fc15-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) This is still a problem in F17. Specifically, the target service which fails is Dell's idrac. (In reply to comment #12) I can confirm this. (In reply to comment #14) > (In reply to comment #12) > I can confirm this. Just encountered this with some Dell machines, too. (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > I can confirm this. > Just encountered this with some Dell machines, too. One more confirmation here, iDRAC6 firmware 1.70 (Build 21). Confirmed with java-1.7.0-openjdk-1.7.0.3-2.2.1.fc17.8.x86_64 on Dell iDRAC6. Seeing this with SuperMicro IPMI console application and java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.i686. This problem is affecting the Fedora system management with the IBM built in console applications java-1.7.0-openjdk.i686 1:1.7.0.5-2.2.1.fc17.9 @updates java-1.7.0-openjdk.x86_64 1:1.7.0.5-2.2.1.fc17.9 @updates Some sort of work around would be nice ;). A workaround (which I use as I need to work with a lot of DRACs at my day job) is to uninstall the IcedTea plugin RPM, download the JDK RPM from Oracle and install. Then symlink the provided .so plugin into your Firefox, e.g.: # ln -s /usr/java/jdk1.7.0_05/jre/lib/amd64/libnpjp2.so /usr/lib64/mozilla/plugins/libnpjp2.so The DRACs work fine with the official RPM from Oracle - this bug's been open for almost a year and a half. :( Icedtea-web, which is replacement of openjdk-plugin have been heavily enhanced in last year. I would like to test your DRAc issues on head and soon to be released 1.3 Second reproducer mentioned here works fine with 1.3. I have tried comment #13, but I was unable to loggin. for f17 - there have been spotted regressions due to jdk7 - eg.: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=843 Confirm same problem with all iDRAC6 versions I've used, both with Chrome and Firefox. I'm on Fedora17, latest errata applied. Versions: java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.x86_64 icedtea-web-1.2-2.fc17.x86_64 Error message I get: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:778) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed. at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:283) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:203) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:317) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770) ... 2 more Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed. at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:283) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:203) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:317) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889) You pretty much can't use a KVM until this bug is fixed, since they rely on JNLP for remote console viewing. 18 months and counting... I also note that invoking javaws -nosecurity launch.jnlp seems to have no effect - whatever "-nosecurity" does, it's not related to jar signing exceptions. Sigh... This is the same issue as the one seen in 753960. Sorry about this, it is only evident with JDK7 and happens when a certificate presented by an https site has a different domain name associated with it than the actual domain. We are working on a fix right now but it is rather complex due to the changes that JDK7 introduced :( *** This bug has been marked as a duplicate of bug 753960 *** Hoping to see a solution soon as I'm beginning to work with new Dell Servers (R720) and iDRAC7 (fw 1.20.20) and I see the same problem. In my case: Fedora 17 and icedtea-web-1.2-2.fc17.x86_64 Thanks in advance, Gianluca Confirming again, This is still open with icedtea-web-1.3-1.fc17.x86_64 and java-1.7.0-openjdk-1.7.0.9-2.3.3.fc17.1.x86_64 net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:778) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:552) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:889) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed. at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:312) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:232) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:357) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:330) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:770) ... 2 more Hi Colin, Can you please try the RPMS here? http://people.redhat.com/dbhole/fedora/icedtea-web/ |