java-1.7.0-icedtea-plugin runs signed applets in untrusted mode.
*** Bug 302071 has been marked as a duplicate of this bug. ***
*** Bug 415061 has been marked as a duplicate of this bug. ***
Test case from other bug: Description of problem: Tried to access a test applet for the Swedish BankID (electronic authorization used by most Swedish citizens) but it doesn't run in IcedTea unfortunately... Version-Release number of selected component (if applicable): java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8 java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8 How reproducible: Every time, visit this webpage: https://test.bankid.com/TestBankidCom/Templates/TestPage.aspx?id=29 Actual results: Text in white on blue: "Applet was not granted necessary rights and is unable to run. Please contact your support line if this problem persists." (The problem persists.) Expected results: Applet should run. If you need me to run any debug traces etc, tell me. But accessing the web page should be the only necessary test and debug tool needed.
Experimental signed applet support has recently been added to IcedTea. The README file in the IcedTea repository has more information on how to enable building of this feature. Please note that since this feature is experimental, it is not enabled by default.
This feature has not hit Rawhide yet. The support is in the RPM but not enabled. People interested in trying this can checkout java-1.6.0-openjdk from CVS, include --enable-netx-plugin on the icedteaopt line and build new RPMs. Signed applet support may be included in a Fedora 9 java-1.6.0-openjdk update.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Visiting my testcase after building --enable-netx-plugin gives the following firefox bomb on this x86_64 host: GCJ PLUGIN: thread 0x93aef0: NP_Initialize GCJ PLUGIN: thread 0x93aef0: plugin_test_appletviewer GCJ PLUGIN: thread 0x93aef0: plugin_test_appletviewer return GCJ PLUGIN: thread 0x93aef0: NP_Initialize: using /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/../../bin/pluginappletviewer GCJ PLUGIN: thread 0x93aef0: NP_Initialize return GCJ PLUGIN: thread 0x93aef0: GCJ_New GCJ PLUGIN: thread 0x93aef0: plugin_data_new GCJ PLUGIN: thread 0x93aef0: plugin_data_new return GCJ PLUGIN: thread 0x93aef0: plugin_get_documentbase GCJ PLUGIN: thread 0x93aef0: plugin_get_documentbase return GCJ PLUGIN: thread 0x93aef0: GCJ_New: creating input fifo: /home/linus/.gcjwebplugin/gcj-instance-26935-0-appletviewer-to-plugin GCJ PLUGIN: thread 0x93aef0: GCJ_New: created input fifo: /home/linus/.gcjwebplugin/gcj-instance-26935-0-appletviewer-to-plugin GCJ PLUGIN: thread 0x93aef0: GCJ_New: creating output fifo: /home/linus/.gcjwebplugin/gcj-instance-26935-0-plugin-to-appletviewer GCJ PLUGIN: thread 0x93aef0: GCJ_New: created output fifo: /home/linus/.gcjwebplugin/gcj-instance-26935-0-plugin-to-appletviewer GCJ PLUGIN: thread 0x93aef0: plugin_start_appletviewer GCJ PLUGIN: thread 0x93aef0: plugin_start_appletviewer return GCJ PLUGIN: thread 0x93aef0: GCJ_New: got confirmation that appletviewer is running. GCJ PLUGIN: thread 0x93aef0: plugin_create_applet_tag GCJ PLUGIN: thread 0x93aef0: plugin_create_applet_tag return GCJ PLUGIN: thread 0x93aef0: plugin_send_message_to_appletviewer ** ** GLib:ERROR:(giochannel.c:2129):IA__g_io_channel_write_chars: code should not be reached /usr/lib64/firefox-3.0b5/run-mozilla.sh: line 131: 26935 Avbruten (SIGABRT) "$prog" ${1+"$@"} [linus@c83-254-42-36 ~]$ PIPE: appletviewer wrote: running PIPE: appletviewer read: null APPLETVIEWER: exiting appletviewer
Adding patrickm to the cc list as the manager of the disabled user fitzsim who reported this bug
(In reply to comment #5) > This feature has not hit Rawhide yet. The support is in the RPM but not > enabled. People interested in trying this can checkout java-1.6.0-openjdk from > CVS, include --enable-netx-plugin on the icedteaopt line and build new RPMs. > > Signed applet support may be included in a Fedora 9 java-1.6.0-openjdk update. Any update on this?
Signed applets are now fully supported as of Rawhide/F10.
Excellent news Deepak, and well done by everyone involved.
Which version of openjdk includes support for this? I'm running rawhide and pulled these: java-1.6.0-openjdk-1.6.0.0-4.b12.fc10.i386 java-1.6.0-openjdk-plugin-1.6.0.0-4.b12.fc10.i386 From Koji -- the release notes don't mention this bz as being fixed so I'm suspicious it's not the correct release yet. And sure enough still getting: netx: Initialization Error: Could not initialize applet. (net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal error occurred while trying to verify jars.) errors with the Juniper Networks Network Connect client (work VPN).
I cant confirm that the homebanking i use work with openjdk and signed applets in rawhide, for the first time i don't need to install the sun binaries to make it work. Keep up the great work !
Ray, the version you are using is the right one. The failure you are seeing appears to be a site-specific issue. Can you please retry the site, this time starting firefox from console with variable ICEDTEAPLUGIN_DEBUG=true, and then attach the resulting log and /tmp/java.stderr (file is created when ICEDTEAPLUGIN_DEBUG=true)? Also, note that debug output contains all kinds of data. Depending on how the applet was written, it *might* contain sensitive info (though very unlikely). It'd be best to therefore scan the file for any personal information before attaching.
tried the above mentioned updates for F10 on a F9-system (okay, with a --nodeps to skip the dep to ca-certificates). Works like a charme. Now signed applets work great, it seems, with F9. Any chance to get that update to show up in F9 as well, maybe at least for updates-testing?
Created attachment 323727 [details] Stderr output -- Junpier Network Connect
(In reply to comment #14) > Ray, the version you are using is the right one. > > The failure you are seeing appears to be a site-specific issue. Can you please > retry the site, this time starting firefox from console with variable > ICEDTEAPLUGIN_DEBUG=true, and then attach the resulting log and > /tmp/java.stderr (file is created when ICEDTEAPLUGIN_DEBUG=true)? > > Also, note that debug output contains all kinds of data. Depending on how the > applet was written, it *might* contain sensitive info (though very unlikely). > It'd be best to therefore scan the file for any personal information before > attaching. See attached. Thanks for taking a look. Also had filed a bug for this upstream FYI.
Created attachment 323730 [details] Log from non-working applet (Supermicro IPMI console)
Please see atteched log from a non-working applet (tested against above mentioned F10-version of icedtea). It essentially fails with: IcedTeaPlugin.cc:3809: Error: Failed to flush bytes to output channel: Broken pipe which e.g. somebody also filed on the Ubuntu-tracker: https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/198093 Didn't find workarounds to try out though. PS: Site for this as well as the applet are accessed through https - does that make a difference?
Hmm, loading the applet itself through http instead of https seems to solve the problem. The applet itself then uses https anyway though - but that works. Somebody with a clue: Is this related or is applet-loading (of signed applets) through https a separate issue?
I know at least in my case the https site in question is using a self-signed cert. I don't know why this would be an issue though as I assume the web browser is handling the transport of the jar files.......
(In reply to comment #14) > Ray, the version you are using is the right one. > > The failure you are seeing appears to be a site-specific issue. Can you please > retry the site, this time starting firefox from console with variable > ICEDTEAPLUGIN_DEBUG=true, and then attach the resulting log and > /tmp/java.stderr (file is created when ICEDTEAPLUGIN_DEBUG=true)? > > Also, note that debug output contains all kinds of data. Depending on how the > applet was written, it *might* contain sensitive info (though very unlikely). > It'd be best to therefore scan the file for any personal information before > attaching. Should I re-open this bug or rely on the one upstream? Just thinking you coder folks might not see this now that it's closed if there's no additional activity. :-) Thanks!
This bug should remain closed. Individual bugs should be opened for specific sites that don't work. That said, I am currently looking into the last 2 outstanding issues mentioned in this bug (juniper networks one and the supermicro one) -- I have not forgotten those :)
(In reply to comment #23) > This bug should remain closed. Individual bugs should be opened for specific > sites that don't work. What about bug 415061 about the Swedish "Bank ID". It was closed as a duplicate of this, and reproduced in comment 3 in this bug. But the problem still remains with java-1.6.0-openjdk-plugin-1.6.0.0-6.b12.fc10.x86_64. The URL has changed slightly in the mean time. The current test case is: https://test.bankid.com/TestBankidCom/Templates/TestPage.aspx?id=22 Should this bug be reopened? Should bug 415061 be reopened? Or do you want a brand new bug number? :-)
There was no reply to comment 24, so now I've filed bug 477351. In case anyone here is interested to follow it.