Bug 480487 - java-1.6.0-openjdk-plugin does not work with Juniper VPN client
java-1.6.0-openjdk-plugin does not work with Juniper VPN client
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-17 12:01 EST by Philippe Troin
Modified: 2009-06-15 01:03 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 509153 (view as bug list)
Environment:
Last Closed: 2009-03-03 10:51:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Iced Tea debug output from Juninper connection attempt. (40.72 KB, text/plain)
2009-02-17 10:38 EST, Ray Van Dolson
no flags Details
Firefox standard output from Juniper connection attempt (13.43 KB, text/plain)
2009-02-17 10:38 EST, Ray Van Dolson
no flags Details

  None (edit)
Description Philippe Troin 2009-01-17 12:01:23 EST
Description of problem:
Accessing a Juniper VPN client applet crashes the Java plugin:

% firefox
ICEDTEAPLUGIN_DEBUG = (null)
Initializing JVM...
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start()
Jar string: ncLinuxLauncher.jar
jars length: 1
JNLPRuntime already initialized
java.util.zip.ZipException: error in opening zip file
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:131)
	at java.util.jar.JarFile.<init>(JarFile.java:150)
	at java.util.jar.JarFile.<init>(JarFile.java:101)
	at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:227)
	at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:202)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:641)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:325)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:157)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:214)
	at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
	at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
java.util.zip.ZipException: error in opening zip file
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:131)
	at java.util.jar.JarFile.<init>(JarFile.java:150)
	at java.util.jar.JarFile.<init>(JarFile.java:101)
	at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:227)
	at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:202)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:641)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:325)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:157)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:214)
	at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
	at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
netx: Initialization Error: Could not initialize applet. (net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal error occurred while trying to verify jars.)
netx: Initialization Error: Could not initialize applet. (net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal error occurred while trying to verify jars.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
	at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:472)
	at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:331)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:157)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:214)
	at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
	... 2 more
Caused by: 
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:331)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:157)
	at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:214)
	at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
	at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
IcedTeaPlugin.cc:3850: Error: Failed to flush bytes to output channel: Broken pipe

At this point, firefox is hosed and won't close.

Version-Release number of selected component (if applicable):
java-1.6.0-openjdk-plugin-1:1.6.0.0-8.b14.fc11.x86_64
I also tried the F10 released package:
java-1.6.0-openjdk-plugin-1.6.0.0-7.b12.fc10.x86_64.rpm

How reproducible:
Always.
Comment 1 Lillian Angel 2009-01-19 10:10:07 EST
Deepak- can you comment on this? Was this fixed upstream?
Comment 2 Deepak Bhole 2009-01-19 15:38:45 EST
There are a set of similar issues, all caused by lack of a UI for accepting https certificates -- I think that might be the problem here too. Work on this is ongoing upstream, and should be done really soon. I'll add a comment to this bug once it is fixed.
Comment 3 Deepak Bhole 2009-02-10 16:28:52 EST
Should be fixed in java-1.6.0-openjdk-1.6.0.0-9.b14.fc10
Comment 4 Ray Van Dolson 2009-02-16 18:09:56 EST
Still getting the following with the latest openjdk:

java.util.zip.ZipException: error in opening zip file
  at java.util.zip.ZipFile.open(Native Method)
  at java.util.zip.ZipFile.<init>(ZipFile.java:131)
  at java.util.jar.JarFile.<init>(JarFile.java:150)
  at java.util.jar.JarFile.<init>(JarFile.java:101)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:245)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:220)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:660)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:330)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
java.util.zip.ZipException: error in opening zip file
  at java.util.zip.ZipFile.open(Native Method)
  at java.util.zip.ZipFile.<init>(ZipFile.java:131)
  at java.util.jar.JarFile.<init>(JarFile.java:150)
  at java.util.jar.JarFile.<init>(JarFile.java:101)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJar(JarSigner.java:245)
  at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:220)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:660)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:330)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet.
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:472)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:336)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  ... 2 more
Caused by:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal error occurred while trying to verify jars.
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:336)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:161)
  at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:218)
  at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
  at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
  at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
java.lang.NullPointerException
  at net.sourceforge.jnlp.NetxPanel.runLoader(NetxPanel.java:97)
  at sun.applet.AppletPanel.run(AppletPanel.java:380)
  at java.lang.Thread.run(Thread.java:636)
java.lang.NullPointerException
  at sun.applet.AppletPanel.run(AppletPanel.java:430)
  at java.lang.Thread.run(Thread.java:636)

$ rpm -q java-1.6.0-openjdk
java-1.6.0-openjdk-1.6.0.0-9.b14.fc10.i386
Comment 5 Ray Van Dolson 2009-02-16 18:46:33 EST
I should note that at least now the plugin prompts me if I want to allow the applet to be trusted and run, but once I answer yes to this, the above errors appear in the terminal and the applet doesn't start correctly.

Anyone out there actually have success with this?
Comment 6 Deepak Bhole 2009-02-17 10:12:59 EST
Can try again after clearing the cache? To clear the cache, run 'rm -rf ~/.icedteaplugin/cache' under your normal username.

If the problem still persists after that:

Please run firefox from command-line as 'ICEDTEAPLUGIN_DEBUG=true firefox' and post the output, and the /tmp/java.std* files that are created after trying to load the site.

Additionally, please also post the output of 'find ~/.icedteaplugin/cache -type f '

Sorry that the latest update doesn't fix the problem.. without access to a reproducible test case, I was guessing that https was the problem.. however it doesn't seem to be :(
Comment 7 Ray Van Dolson 2009-02-17 10:38:16 EST
Created attachment 332228 [details]
Iced Tea debug output from Juninper connection attempt.
Comment 8 Ray Van Dolson 2009-02-17 10:38:39 EST
Created attachment 332229 [details]
Firefox standard output from Juniper connection attempt
Comment 9 Ray Van Dolson 2009-02-17 10:39:46 EST
No worries, this seems to be a fun one to track down!  Attached the results as requested and here's the contents of the cache directory:

$ find ~/.icedteaplugin/ -type f
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar.info
Comment 10 Deepak Bhole 2009-02-17 11:09:34 EST
Hmm, so it looks like it did try to download the jar file... Can you please post output of 

ls -l /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

and 

file /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

connectdev.domain.com being replaced with the appropriate domain ofcourse!
Comment 11 Ray Van Dolson 2009-02-17 11:26:37 EST
$ ls -l /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
-rw-rw-r-- 1 rayvd rayvd 4784 2009-02-17 07:31 /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar

[rayvd@tinyox ~]$ file /home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
/home/rayvd/.icedteaplugin/cache/https/connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar: ASCII HTML document text, with very long lines

Sorry for the word wrap.

Interesting.  HTML file?  Examining the content it appears to be the HTML login page...
Comment 12 Ray Van Dolson 2009-02-17 11:32:17 EST
Also, let me know if you'd prefer I open an SR and another (private) bz for this against RHEL5 openjdk.  Might be able to provide more useful output or other more detailed information.
Comment 13 Deepak Bhole 2009-02-17 13:46:34 EST
Yep, that HTML file certainly explains the exception. The question though, is why. Can you try these  commands and paste the output:

wget https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
ls -l ncLinuxLauncher.jar
file ncLinuxLauncher.jar
rm -f ncLinuxLauncher.jar

wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318 Fedora/3.0.2-1.fc9 Firefox/3.0.2" https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
ls -l ncLinuxLauncher.jar
file ncLinuxLauncher.jar
rm -f ncLinuxLauncher.jar

I am wondering if the server is refusing to serve the jar file to non browser clients. The above should clarify that..
Comment 14 Naveed Hasan 2009-02-17 14:21:11 EST
https://bugzilla.redhat.com/show_bug.cgi?id=473141 looks like the same issue.
Comment 15 Deepak Bhole 2009-02-17 14:36:58 EST
Actually, I am pretty sure 473141 was https related and is fixed now. I was provided with a test site similar to that bug and it works with the latest version.
Comment 16 Ray Van Dolson 2009-02-17 20:58:09 EST
(In reply to comment #13)
> Yep, that HTML file certainly explains the exception. The question though, is
> why. Can you try these  commands and paste the output:
> 
> wget https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
> ls -l ncLinuxLauncher.jar
> file ncLinuxLauncher.jar
> rm -f ncLinuxLauncher.jar
> 
> wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2) Gecko/2008092318
> Fedora/3.0.2-1.fc9 Firefox/3.0.2"
> https://connectdev.domain.com/dana-cached/nc/ncLinuxLauncher.jar
> ls -l ncLinuxLauncher.jar
> file ncLinuxLauncher.jar
> rm -f ncLinuxLauncher.jar
> 
> I am wondering if the server is refusing to serve the jar file to non browser
> clients. The above should clarify that..

Neither download the .jar file.  Both fire up the welcome.cgi page containing the authentication form.

Maybe the plugin isn't passing along the cookie information required to identify the session correctly?  The server assumes an unauthenticated request and this is why we're getting HTML output...

I might be able to verify this with wireshark if needed.....
Comment 17 Deepak Bhole 2009-02-18 09:55:43 EST
The plugin definitely doesn't pass the cookie information. I am not sure if the Sun one does either.. in any case, can you try downloading the file by entering the URL in firefox? Atleast that will rule out a 404/auto redirect....
Comment 18 Ray Van Dolson 2009-02-18 10:11:08 EST
It works from Firefox if I've correctly authenticated (hmm, I wonder if I save the .jar file to that cache directory if I could then connect successfully with icedtea...)

It gives me the login page from Firefox if I have not authenticated correctly first (likely the same welcome.cgi we see from wget).

Not sure how the Sun plugin handles this except to say that it is able to load the .jar up somehow.  The whole login process does look slightly different.  The Sun plugin seems to stick to the same page whereas the OpenJDK one seems to jump over to another blank page first.

I'm going to look into getting my hands on the crt file for the https connection and see if I can get wireshark to peer inside the connection and determine what's different about the requests.

Would an ogg via istanbul of the login process with Sun vs OpenJDK be helpful to you?

Thanks much.
Comment 19 Ray Van Dolson 2009-02-18 10:21:29 EST
I did snag a capture via istanbul comparing logins via Sun vs OpenJDK plugin.  If you're interested, I can email it to you directly.
Comment 20 Deepak Bhole 2009-02-18 10:59:52 EST
Oh yes, please! It'd be very helpful to see the wire data if cookies/authentication is happening with the Sun plugin and not ours. Thanks.
Comment 21 Deepak Bhole 2009-02-19 18:33:55 EST
*** Bug 482943 has been marked as a duplicate of this bug. ***
Comment 22 Ray Van Dolson 2009-02-22 22:04:29 EST
Well, couldn't get the private key file I needed from work, so, after many trials and tribulations setting up an Apache proxy and the correct cipher settings to allow Wireshark to actually decrypt things (BTW, Java and Firefox appear to use different DNS resolving mechanisms :), I did manage to grab two sessions -- one with Sun's plugin and another with IcedTea's.

Sun's definitely is sending cookie information, and in response gets back the proper .jar file.  IcedTea does not and instead gets a 302 response that redirects back to the welcome page.

I will email these files to your personal email account.  Probably nothing too sensitive in them except for some old expired session id's, but just to be on the prudent side.

Let me know if you need anything else.
Comment 23 Ray Van Dolson 2009-02-22 22:19:13 EST
PS, the following snippet is inside the applet block on the page that kicks off the client.

<script language="JavaScript">
  document.write(' <param name=cookies value=\"' + document.cookie + '\">');
</script>
Comment 24 Naveed Hasan 2009-02-23 00:19:23 EST
(In reply to comment #22)
> Well, couldn't get the private key file I needed from work, so, after many
> trials and tribulations setting up an Apache proxy and the correct cipher
> settings to allow Wireshark to actually decrypt things (BTW, Java and Firefox
> appear to use different DNS resolving mechanisms :), I did manage to grab two
> sessions -- one with Sun's plugin and another with IcedTea's.


If and when you have the time, it would be very helpful and time efficient if you could post about exactly what you needed to do to get the Juniper Network Connect + Apache proxy + Wireshark packet capture set up usefully. I am doing some research into how difficult it'd be to implement a pure OSS solution to connecting to Juniper SSL VPNs. David Woodhouse has done some interesting things[1] for Cisco AnyConnect VPNs, resulting in NetworkManager-openconnect being available in Fedora. I wonder if any of that work is portable to Juniper. Thanks!

[1] http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2008-September/002577.html
Comment 25 Ray Van Dolson 2009-02-23 03:30:53 EST
Posted an initial blog entry here[1] describing what I did.  Hopefully I didn't miss anything. :-)

[1] http://www.bludgeon.org/~rayvd/blog/fedora/juniper.html
Comment 26 Ray Van Dolson 2009-02-24 01:29:21 EST
I can now connect successfully with the scratch build of openjdk that Deepak built today.

java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.i386

Connected to my work VPN as we speak!  Thanks much Deepak.  How soon can we expect this to show up in RHEL?

Thanks again.
Comment 27 Pontus Enhager 2009-02-24 04:47:29 EST
is there a way to get that build from somewhere to test my bug (dupe of this one) as well ?
Comment 28 Deepak Bhole 2009-02-24 09:27:11 EST
For anyone that may want the fix right away, here is a tentative build with the latest version of the plugin, that resolves this issue. Thanks to Ray for verifying!

http://koji.fedoraproject.org/koji/taskinfo?taskID=1149662

I will close this issue when we push out an official build with the changes.
Comment 29 Pontus Enhager 2009-02-24 09:57:05 EST
this actually makes the situation worse for me - now i cannot even login

is there any info you'd like ?

Should we handle that in this bug or in my old bug ?
Comment 30 Ray Van Dolson 2009-02-24 10:06:46 EST
(In reply to comment #29)
> this actually makes the situation worse for me - now i cannot even login
> 
> is there any info you'd like ?
> 
> Should we handle that in this bug or in my old bug ?

You can't log in via the webpage or.... ?  Maybe the old .jar file is still cached.  Make sure and rm -rf ~/.icedteaplugin/cache first.
Comment 31 Pontus Enhager 2009-02-24 10:19:10 EST
i cannot login via the homepage 

https://auth1.forsakringskassan.se/necs/bidlogon.jsp?TARGET=https://gate1.forsakringskassan.se/portal2/

even after removing the icedteaplugin cache

i just get a grey box whereas i would normally get a login prompt
Comment 32 Pontus Enhager 2009-02-24 10:21:40 EST
please note that all my problems are in detail described in https://bugzilla.redhat.com/show_bug.cgi?id=482943

rather than here
Comment 33 Deepak Bhole 2009-02-24 10:27:17 EST
Hmm, that is odd. According to the analysis on that bug, the problem was cookies not being sent by the plugin. I will reopen that bug and we can track it there.
Comment 34 Deepak Bhole 2009-02-24 11:02:19 EST
By the way, the above build is a scratch build, so it may be gone any time. We are working on a new F-10/Rawhide update. In the mean time, Gary Benson from here at RedHat has graciously offered to host the files. They are located here.

http://gbenson.net/dbhole/

checksums are as follows:

1f7ed0ae0566ed92218365c9c33a5971  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.i386.rpm
cf19a27fc0e4d6feb564d8cdc4b0bd0e  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.src.rpm
608dc1a3a09fd48027baf0366e24cf30  java-1.6.0-openjdk-1.6.0.0-10.b14.1.fc10.x86_64.rpm
38347f2002508e47e87b39f86db58c2d  java-1.6.0-openjdk-debuginfo-1.6.0.0-10.b14.1.fc10.i386.rpm
803906a8122a8bd5133be0909b0ae509  java-1.6.0-openjdk-debuginfo-1.6.0.0-10.b14.1.fc10.x86_64.rpm
6ddaae595d8cae08e424dfe8b7d48745  java-1.6.0-openjdk-demo-1.6.0.0-10.b14.1.fc10.i386.rpm
ef258135088a92507f76024eb6f17309  java-1.6.0-openjdk-demo-1.6.0.0-10.b14.1.fc10.x86_64.rpm
f0ebd2907bb143e0fe2846fd107f46e1  java-1.6.0-openjdk-devel-1.6.0.0-10.b14.1.fc10.i386.rpm
2e2d7124d31d45d3cd085a4fbad49d35  java-1.6.0-openjdk-devel-1.6.0.0-10.b14.1.fc10.x86_64.rpm
32655a7f1607f321675f49b98945ff9f  java-1.6.0-openjdk-javadoc-1.6.0.0-10.b14.1.fc10.i386.rpm
a8c95428c6f277e783c8abb8301d9ce1  java-1.6.0-openjdk-javadoc-1.6.0.0-10.b14.1.fc10.x86_64.rpm
103c7c511dff60eba17320cdd3751081  java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.i386.rpm
6c0e7dbe0c773864f182f085822d44a2  java-1.6.0-openjdk-plugin-1.6.0.0-10.b14.1.fc10.x86_64.rpm
92d01ac954cb5db29e95e47fac9b477b  java-1.6.0-openjdk-src-1.6.0.0-10.b14.1.fc10.i386.rpm
13914fd3535a03aa9ac396c1c2c7010e  java-1.6.0-openjdk-src-1.6.0.0-10.b14.1.fc10.x86_64.rpm
Comment 35 Lillian Angel 2009-02-25 14:17:14 EST
fix will be in rawhide within the next couple of days
Comment 36 Ray Van Dolson 2009-02-25 14:24:04 EST
Thanks guys for your work on this.

Will this be slated for RHEL 5 as well?  Errata to 5.3 or targeted for 5.4?

Would you recommend I open an SR?
Comment 37 Lillian Angel 2009-02-25 14:29:41 EST
the openjdk plugin is not available in RHEL.
Comment 38 Ray Van Dolson 2009-02-25 14:37:17 EST
(In reply to comment #37)
> the openjdk plugin is not available in RHEL.

My mistake.  It's in EPEL.  I'll poke the EPEL maintainer.
Comment 39 Ray Van Dolson 2009-03-15 19:00:37 EDT
Are you guys planning to release this for Fedora 10 officially?
Comment 40 Lillian Angel 2009-03-16 16:02:22 EDT
No update for F-10 has been discussed yet. Possibly when we release IcedTea6-1.5. No timeframe either.
Comment 41 Pontus Enhager 2009-05-12 13:00:36 EDT
ehm seeing my problem again

java-1.6.0-openjdk-plugin-1.6.0.0-15.b14.fc10.i386
java-1.6.0-openjdk-1.6.0.0-15.b14.fc10.i386


should i try to get a trace or si this the wrong version - is thera any way to get hold of a working build again ?

brg Pontus
Comment 42 Lillian Angel 2009-05-12 13:07:11 EDT
This hasn't been updated in F-10 yet. Check rawhide. It will be in the next release.
Comment 43 Pontus Enhager 2009-05-12 13:12:04 EDT
ahh sweet (mee smacking forehead after finding old builds on other computer lying around at home)

sorry for the fuzz
Comment 44 Mike C 2009-05-19 11:46:31 EDT
Can you tell me if a fix for this will be in updates-testing (or is there already)? I am affected by this bug and am very interested to see a fix. If not in updates testing is there a time-frame for a fix going to either updates-testing or updates?

Thanks
Comment 45 Kedar Patankar 2009-06-15 01:03:24 EDT
The openjdk b14.1 RPMS mentioned above in comments for this bug don't work for me. My company has a Juniper netscreen VPN box. It works perfectly with SUN JRE. With the above RPMS, I get a dialog box asking about running the appet/trusting the publisher. I answer yes always for all the dialogs. It starts the applet, but then quits saying "Config failed".

I tried F11 with openjdk 22.b16 update. No luck.

I would be glad to provide any debugging data.

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