Bug 675271 - javaws no longer will run app that previously ran fine
javaws no longer will run app that previously ran fine
Status: CLOSED DUPLICATE of bug 753960
Product: Fedora
Classification: Fedora
Component: icedtea-web (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Omair Majid
Fedora Extras Quality Assurance
:
: 738811 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-04 13:36 EST by long
Modified: 2012-10-31 13:59 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-24 16:12:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
jarsigner -verify -verbose sinetfactory.jar (77.14 KB, text/plain)
2011-02-07 12:21 EST, long
no flags Details
.JAR file which causes the problem reported in this issue too (1.10 MB, application/x-java-archive)
2011-11-16 04:24 EST, Peter Hanecak
no flags Details

  None (edit)
Description long 2011-02-04 13:36:20 EST
Description of problem:
After the upgrade to 49.1.8.5.fc13 javaws now throws exceptions when trying to run an app that used to work fine:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application.
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:651)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:420)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:732)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars.
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:216)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:170)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:641)
        ... 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:216)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:170)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:641)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:420)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:732)


Version-Release number of selected component (if applicable):
49.1.8.5.fc13

How reproducible:
always

Steps to Reproduce:
1. javaws ~/src/GUI_WS_NS92Build469nc

2.
3.
  
Actual results:
long@raptor applets]$ javaws ~/src/GUI_WS_NS92Build469nc
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application.
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:651)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:420)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:732)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars.
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:216)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:170)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:641)
        ... 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:216)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:170)
        at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:249)
        at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:641)
        at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:420)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:732)
[long@raptor applets]$ 


Expected results:
netscaler GUI should start

Additional info:
when I use jarsigner to check the jars it says:
[long@raptor applets]$ ls *.jar|xargs -i jarsigner -verify "{}"
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.
jar verified.

Warning: 
This jar contains unsigned entries which have not been integrity-checked. 

Re-run with the -verbose and -certs options for more details.
jar verified.

No where does it say that a JAR file itself failed to verify.
Comment 1 Deepak Bhole 2011-02-05 04:17:01 EST
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.
Comment 2 long 2011-02-07 12:20:46 EST
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?
Comment 3 long 2011-02-07 12:21:21 EST
Created attachment 477461 [details]
jarsigner -verify -verbose sinetfactory.jar
Comment 4 Omair Majid 2011-02-08 19:14:58 EST
Can you grab the packages from http://omajid.fedorapeople.org/java-1.6.0-openjdk/ and check if they fix the problem?
Comment 5 long 2011-02-09 15:27:55 EST
yes, now the applet and app both run again
Comment 6 Bug Zapper 2011-05-30 07:32:29 EDT
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
Comment 7 long 2011-05-31 12:50:04 EDT
still an issue with java-1.6.0-openjdk-1.6.0.0-57.1.10.1.fc15.x86_64
Comment 8 Omair Majid 2011-09-20 16:13:01 EDT
*** Bug 738811 has been marked as a duplicate of this bug. ***
Comment 9 Omair Majid 2011-09-20 16:14:51 EDT
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
Comment 10 Donald Cohen 2011-09-20 17:26:00 EDT
(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.
Comment 11 Peter Hanecak 2011-11-16 04:24:47 EST
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)
Comment 12 Matthew Booth 2012-04-27 06:27:47 EDT
This is still a problem in F17. Specifically, the target service which fails is Dell's idrac.
Comment 14 Boris 2012-06-05 05:39:33 EDT
(In reply to comment #12)
I can confirm this.
Comment 15 Adam Huffman 2012-06-12 08:28:16 EDT
(In reply to comment #14)
> (In reply to comment #12)
> I can confirm this.

Just encountered this with some Dell machines, too.
Comment 16 tengel 2012-06-20 19:09:47 EDT
(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).
Comment 17 Didier 2012-06-25 07:09:50 EDT
Confirmed with java-1.7.0-openjdk-1.7.0.3-2.2.1.fc17.8.x86_64 on Dell iDRAC6.
Comment 18 Orion Poplawski 2012-08-06 18:55:39 EDT
Seeing this with SuperMicro IPMI console application and java-1.7.0-openjdk-1.7.0.5-2.2.1.fc17.9.i686.
Comment 19 Stephen John Smoogen 2012-08-14 19:04:59 EDT
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 ;).
Comment 20 tengel 2012-08-14 19:38:30 EDT
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. :(
Comment 21 jiri vanek 2012-08-15 06:14:20 EDT
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
Comment 23 Jeffrey Watts 2012-08-15 09:50:26 EDT
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)
Comment 24 davidkwood 2012-08-20 10:13:18 EDT
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...
Comment 25 Deepak Bhole 2012-08-24 16:12:52 EDT
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 ***
Comment 26 Gianluca Cecchi 2012-09-04 11:19:19 EDT
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
Comment 27 Colin Panisset 2012-10-25 07:57:39 EDT
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
Comment 28 Deepak Bhole 2012-10-31 13:59:34 EDT
Hi Colin,

Can you please try the RPMS here?

http://people.redhat.com/dbhole/fedora/icedtea-web/

Note You need to log in before you can comment on or make changes to this bug.