Bug 738811

Is this applet public? Do you have a url to it?

ok, finally reconstituted fc15 in a vm, updated all software, installed java, java plugin, here's what I see.
(I had to be root to install all that stuff...)
[root@number11 ~]# firefox 
failed to create drawable
failed to create drawable
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-i386)
OpenJDK Client VM (build 20.0-b11, mixed mode)
system look and feel class: javax.swing.plaf.metal.MetalLookAndFeel
free: 10070 allocated: 17136 max: 496960 total free memory: 489894
hostname saturn.spicenet.net port 443
javax.net.ssl.SSLException: java.security.AccessControlException: access denied (java.security.AllPermission <all permissions> <all actions>)
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1665)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1628)
	at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1611)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1192)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1169)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440)

etc.

The url is
http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html

I think you can get this behavior by just clicking on login without supplying any user or password info, but I'll check.
If necessary I can give you such data.  (D. Lila I think already has it for previous debugging activity.)

This url is even better:
http://saturnids.spicenet.net/sonario/develop081125/develop081125-ids.html
Without any input other than putting the url into the browser:

[don@number11 ~]$ firefox &
[1] 31650
[don@number11 ~]$ failed to create drawable
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-i386)
OpenJDK Client VM (build 20.0-b11, mixed mode)
system look and feel class: com.sun.java.swing.plaf.gtk.GTKLookAndFeel
java.security.AccessControlException: access denied (java.net.NetPermission getProxySelector)
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:393)
	at java.security.AccessController.checkPermission(AccessController.java:553)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:261)
	at java.net.ProxySelector.getDefault(ProxySelector.java:90)
	at Sonario.readProxySettings(Sonario.java:89)
	at Sonario.init(Sonario.java:205)
	at sun.applet.AppletPanel.run(AppletPanel.java:436)
	at net.sourceforge.jnlp.NetxPanel.run(NetxPanel.java:68)
	at java.lang.Thread.run(Thread.java:679)

Ignore comment 2:
> The url is
> http://saturnids.spicenet.net/sonario/develop081125/develop081125-mysql.html

Sorry, that's the url for the other bug, 738814 - that one does require login

On further investigation, it looks like one of the applet's jars, mysql-connector-java-5.1.5-bin.jar, contains an unsigned entry: META-INF/INDEX.LIST

The "fix" explained here makes it work:
http://thread.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/12020

*** This bug has been marked as a duplicate of bug 675271 ***

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.

(In reply to comment #6)
> 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?

Actually, the new jar is completely unsigned (or at least it was last I checked).

> 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?
> 

I dont have the code for the applets, so I cant give a definite answer. FWIW, the stack trace shows that the two applets are suffering from completely different problems.

The ids applet tries to access proxy settings and runs into an error. This is because of the not-completely-signed jar. The entire applet is determined to be unsigned/untrusted code. The code is not granted permission to access proxy settings.

The mysql applet, on the other hand, (as far as I can tell) does not try to access proxy settings. It tries to establish https connections and runs into a problem with that. A code path that I had not considered is taken which needs more permissions to execute.

So the two problems seem very different to me.

> BTW,
> Doesn't this seem the sort of thing that mysql (now oracle!) really should fix?

Looking at mysql-connector-java-5.1.5-bin.jar, it is not signed by oracle, but by "IsComp Systems, Inc."

> Or is it possible that all other java implementation accept unsigned index
> files?

As far as I know, there is just one implementation of plugin/webstart - Oracle's (previously Sun's). And as far as I know, it accepts other unsigned files too:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=722

> 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?

Yes, the fix, if applied locally, would only work for you. However, if the patch was committed to icedtea-web (of which there is a good chance, but other things need to happen first) then the applet will work for other users too.

> I was hoping that I could at least arrange to sign the unsigned entry and then
> have that new jar work for everyone.

The correct fix, IMHO, is to indeed sign all entries in the jar. Given that you (or your company?) signed all the other entries in the jar, signing the INDEX.LIST should not be too difficult.

(In reply to comment #7)
> Actually, the new jar is completely unsigned (or at least it was last I
> checked).
Ok, this makes sense - I had forgotten that I'm the one that has to sign it!
I have now seen this same error in windows using 
JRE version 1.6.0_26-b03 Java HotSpot(TM) Client VM 
and that was in the version using the mysql driver.

> The correct fix, IMHO, is to indeed sign all entries in the jar. Given that you
> (or your company?) signed all the other entries in the jar, signing the
> INDEX.LIST should not be too difficult.

I believe that the original jar, mysql-connector-java-5.1.5-bin.jar, was signed 
like this:
jarsigner -storepass ... [jar file] [alias]
I thought this was supposed to sign the jar as a unit, not individual files in it.
How can I tell that a given entry is signed?
I've just resigned the 5.1.5 jar and signed the 5.1.17 jar and I still get the same error.  Is the problem in jarsigner?  Maybe I can remove INDEX.LIST and resign?

(In reply to comment #8)
> I believe that the original jar, mysql-connector-java-5.1.5-bin.jar, was signed 
> like this:
> jarsigner -storepass ... [jar file] [alias]
> I thought this was supposed to sign the jar as a unit, not individual files in
> it.

You cant actually sign a jar file itself; only the files inside the jar file are signed. But that command should sign everything necessary inside the jar.

> How can I tell that a given entry is signed?

$ jarsigner -verify -verbose [jar file]

All files (not directories) with the exception of signature-related files should be marked as 'sm' 

The openjdk code lists signature-related files as:
    /**
     * signature-related files include:
     * . META-INF/MANIFEST.MF
     * . META-INF/SIG-*
     * . META-INF/*.SF
     * . META-INF/*.DSA
     * . META-INF/*.RSA
     */

> I've just resigned the 5.1.5 jar and signed the 5.1.17 jar and I still get the
> same error.  Is the problem in jarsigner?  Maybe I can remove INDEX.LIST and
> resign?

I just tested signing the unsigned 5.1.17 jar (with a custom certificate) and the META-INF/INDEX.LIST file shows up as signed.

If all the files in the jar are signed and you are still running into this error, please let me know.

$ jarsigner -verify -verbose mysql-connector-java-5.1.5-bin.jar

       23406 Tue Nov 25 09:35:02 GMT-08:00 2008 META-INF/MANIFEST.MF
       23208 Wed Sep 21 12:43:38 GMT-08:00 2011 META-INF/SATURNKE.SF
        1140 Wed Sep 21 12:43:38 GMT-08:00 2011 META-INF/SATURNKE.DSA
           0 Fri Oct 05 21:08:44 GMT-08:00 2007 META-INF/
         443 Fri Oct 05 21:08:44 GMT-08:00 2007 META-INF/INDEX.LIST
           0 Fri Oct 05 21:08:20 GMT-08:00 2007 com/
after that the results look better for non-directories, e.g.,
smk     4758 Fri Oct 05 21:08:30 GMT-08:00 2007 com/mysql/jdbc/Blob.class

So maybe my version of jarsigner erroneously views all META-INF as signature related.
So far I don't see an option to delete a file from the jar.
I guess I could extract it all, delete the file I don't want and then
jar it again.  (Would I have to resign it?)

5.1.17 looks even worse:
$ jarsigner -verify -verbose mysql-connector-java-5.1.17-bin.jar | more

       27600 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/MANIFEST.MF
       25758 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.SF
        1140 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.DSA
           0 Mon Jul 04 16:24:08 GMT-08:00 2011 META-INF/
           0 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/services/
          21 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/services/java.sql.Driv\
er
         463 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/INDEX.LIST
           0 Mon Jul 04 16:23:42 GMT-08:00 2011 com/
 ...

(In reply to comment #10)
> $ jarsigner -verify -verbose mysql-connector-java-5.1.5-bin.jar
> 
>        23406 Tue Nov 25 09:35:02 GMT-08:00 2008 META-INF/MANIFEST.MF
>        23208 Wed Sep 21 12:43:38 GMT-08:00 2011 META-INF/SATURNKE.SF
>         1140 Wed Sep 21 12:43:38 GMT-08:00 2011 META-INF/SATURNKE.DSA
>            0 Fri Oct 05 21:08:44 GMT-08:00 2007 META-INF/
>          443 Fri Oct 05 21:08:44 GMT-08:00 2007 META-INF/INDEX.LIST
>            0 Fri Oct 05 21:08:20 GMT-08:00 2007 com/
> after that the results look better for non-directories, e.g.,
> smk     4758 Fri Oct 05 21:08:30 GMT-08:00 2007 com/mysql/jdbc/Blob.class
> 

Yup, that's exactly what I get on my machine.

> So maybe my version of jarsigner erroneously views all META-INF as signature
> related.

What jarsigner are you using? 
$ rpm -qf $(readlink -f $(which jarsigner))

From the list, only META-INF/INDEX.LIST should be signed - the other META-INF/* files are expected to be not signed (though OpenJDK7 might consider MANIFEST.MF as signed too).

> So far I don't see an option to delete a file from the jar.
> I guess I could extract it all, delete the file I don't want and then
> jar it again.  (Would I have to resign it?)

I am not sure if that works. You can try it out and use jarsigner -verify to check. 

Perhaps it might be easier to grab a new mysql jar and sign it to see if INDEX.LIST gets signed?

> 
> 5.1.17 looks even worse:
> $ jarsigner -verify -verbose mysql-connector-java-5.1.17-bin.jar | more
> 
>        27600 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/MANIFEST.MF
>        25758 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.SF
>         1140 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.DSA
>            0 Mon Jul 04 16:24:08 GMT-08:00 2011 META-INF/
>            0 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/services/
>           21 Mon Jul 04 16:24:06 GMT-08:00 2011
> META-INF/services/java.sql.Driv\
> er
>          463 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/INDEX.LIST
>            0 Mon Jul 04 16:23:42 GMT-08:00 2011 com/
>  ...

Have you signed it? The results look completely standard for unsigned jars.

(In reply to comment #11)
> $ rpm -qf $(readlink -f $(which jarsigner))
java-1_4_2-sun-devel-1.4.2.17-0.2

> Perhaps it might be easier to grab a new mysql jar and sign it to see if
> INDEX.LIST gets signed?
That's what 5.1.17 was.

> > 5.1.17 looks even worse:
> > $ jarsigner -verify -verbose mysql-connector-java-5.1.17-bin.jar | more
> > 
> >        27600 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/MANIFEST.MF
> >        25758 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.SF
> >         1140 Wed Sep 21 12:50:58 GMT-08:00 2011 META-INF/SATURNKE.DSA
> >            0 Mon Jul 04 16:24:08 GMT-08:00 2011 META-INF/
> >            0 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/services/
> >           21 Mon Jul 04 16:24:06 GMT-08:00 2011
> > META-INF/services/java.sql.Driv\
> > er
> >          463 Mon Jul 04 16:24:06 GMT-08:00 2011 META-INF/INDEX.LIST
> >            0 Mon Jul 04 16:23:42 GMT-08:00 2011 com/
> >  ...
> 
> Have you signed it? The results look completely standard for unsigned jars.
After the META-INF, all the non-directories are signed:
           0 Fri Oct 05 21:08:20 GMT-08:00 2007 com/mysql/
           0 Fri Oct 05 21:08:38 GMT-08:00 2007 com/mysql/jdbc/
smk      914 Fri Oct 05 21:08:30 GMT-08:00 2007 com/mysql/jdbc/AssertionFailedException.class
smk     4758 Fri Oct 05 21:08:30 GMT-08:00 2007 com/mysql/jdbc/Blob.class
smk     2116 Fri Oct 05 21:08:32 GMT-08:00 2007 com/mysql/jdbc/BlobFromLocator$
LocatorInputStream.class
smk     8761 Fri Oct 05 21:08:32 GMT-08:00 2007 com/mysql/jdbc/BlobFromLocator.

(In reply to comment #12)
> (In reply to comment #11)
> > $ rpm -qf $(readlink -f $(which jarsigner))
> java-1_4_2-sun-devel-1.4.2.17-0.2
> 

Ahhhh... That explains a lot. Thanks for tracking it down. Would it be possible, at all, to use a newer jarsigner? Just to check, at least?

> > Perhaps it might be easier to grab a new mysql jar and sign it to see if
> > INDEX.LIST gets signed?
> That's what 5.1.17 was.
> 

Oh, I didn't see that. So it looks like your jarsigner is not signing INDEX.LIST files :/

Ok, found another version
java-1.5.0-sun-1.5.0_03
This problem is now solved.
(But now I wonder whether that windows user still has this problem... - will ask)