Possible BUG in Mixed Code Security Warning?

[FutureScalper]

I conclude after much working with this issue that the Security
Warning is somehow erroneously triggered, even though it is explicitly
disabled.

I believe this is a BUG but someone can enlighten me, please? Note
easily reproducible because things work for perhaps several hours
before problems occur. This app needs to run unattended 24 x 7.

If I can't get rid of this, I'll have to back down to Java 6 Update 17
and stay there until it's resolved.

I can run for hours, and then suddenly I get the Security Warning for
mixed code. Everything is signed, and the system is configured as
follows, with Web Start as the deployer.

The app does not contain any custom classloaders, nor do anything
except just run standalone.

In Windows/Sun/Java/Deployment (which is definitely being used)

deploiyment.config contains:
deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
deployment.properties
deployment.system.config.mandatory=true

deployment.properties contains:
deployment.security.mixcode=DISABLE

C:\Windows\SysWOW64>java -server -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

The following exception is false. Signer information is the same in
all packages, as far as I know. (I signed everything and control the
deployment.)

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
class "com.twc.trader.SupportResistanceDialog$1"'s signer information
does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
at com.twc.trader.TickAnalyzer.update(Unknown Source)
at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
Source)
at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
Source)
at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

 

[FutureScalper]

I conclude after much working with this issue that the Security
Warning is somehow erroneously triggered, even though it is explicitly
disabled.

I believe this is a BUG but someone can enlighten me, please?  Note
easily reproducible because things work for perhaps several hours
before problems occur.  This app needs to run unattended 24 x 7.

If I can't get rid of this, I'll have to back down to Java 6 Update 17
and stay there until it's resolved.

I can run for hours, and then suddenly I get the Security Warning for
mixed code.  Everything is signed, and the system is configured as
follows, with Web Start as the deployer.

The app does not contain any custom classloaders, nor do anything
except just run standalone.

In Windows/Sun/Java/Deployment (which is definitely being used)

deploiyment.config contains:
deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
deployment.properties
deployment.system.config.mandatory=true

deployment.properties contains:
deployment.security.mixcode=DISABLE

C:\Windows\SysWOW64>java -server -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

The following exception is false.  Signer information is the same in
all packages, as far as I know.  (I signed everything and control the
deployment.)

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
class "com.twc.trader.SupportResistanceDialog$1"'s signer information
does not match signer information of other classes in the same package
        at java.lang.ClassLoader.checkCerts(Unknown Source)
        at java.lang.ClassLoader.preDefineClass(Unknown Source)
        at java.lang.ClassLoader.defineClassCond(Unknown Source)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$000(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
        at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
        at com.twc.trader.TickAnalyzer.update(Unknown Source)
        at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
Source)
        at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
Source)
        at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

OK, I see a couple of typos in my post, but I can assure you that
deployment.config is correct, is being used, and deployment.properties
is mandatory, and my understanding is that the property will DISABLE
Security Warning checking.

But, several instances of my app fail at different random points,
after many hours of running, and there appears to be no pattern except
that the Security Warning behavior reappears for no apparent reason
when the GUI tries some action. Apparently random.

 

[Eric Sosman]

[...]
I believe this is a BUG but someone can enlighten me, please? Note
easily reproducible because things work for perhaps several hours
before problems occur. This app needs to run unattended 24 x 7.
[...]
I can run for hours, and then suddenly I get the Security Warning for
mixed code. Everything is signed, and the system is configured as
follows, with Web Start as the deployer.

The app does not contain any custom classloaders, nor do anything
except just run standalone.

This seems odd. You say it runs "standalone" and "unattended,"
yet the exception occurs on thread AWT-EventQueue-0, which suggests
that there's a GUI somewhere. The stack trace seems to show that a
mouse click is being processed by Swing components -- if the app is
standalone and unattended, who's clicking mouse buttons?

Also, the app doesn't merely "run for hours" and suddenly hit
trouble while doing the same things it's been doing all along. The
JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
class, which it wouldn't be doing if it had been using that class
"for hours" and had thus loaded it earlier; this is the first time
com.twc.trader.SupportResistanceDialog$1 has been called for. (It's
possible for a class to be loaded, discarded, and re-loaded, but
since you say you're doing no ClassLoader trickery that seems fairly
unlikely.) I think you should focus your attention on the signing of
this seldom-used nested class, and see if that turns up anything of
interest. At the very least, knowing the particular class that's
involved may help you reproduce the problem with less waiting around.

I don't know whether it makes a difference, but the troublesome
class is being loaded from the network, not from a local source. Maybe
you've got a mismatched mixture of old, cached classes with fresh
somewhere-over-the-network classes? It might be helpful to turn on the
JVM's trace of class-loading activity, and see if anything's weird.

Good luck!

 

[FutureScalper]

[...]
I believe this is a BUG but someone can enlighten me, please?  Note
easily reproducible because things work for perhaps several hours
before problems occur.  This app needs to run unattended 24 x 7.
[...]
I can run for hours, and then suddenly I get the Security Warning for
mixed code.  Everything is signed, and the system is configured as
follows, with Web Start as the deployer.

The app does not contain any custom classloaders, nor do anything
except just run standalone.

     This seems odd.  You say it runs "standalone" and "unattended,"
yet the exception occurs on thread AWT-EventQueue-0, which suggests
that there's a GUI somewhere.  The stack trace seems to show that a
mouse click is being processed by Swing components -- if the app is
standalone and unattended, who's clicking mouse buttons?

     Also, the app doesn't merely "run for hours" and suddenly hit
trouble while doing the same things it's been doing all along.  The
JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
class, which it wouldn't be doing if it had been using that class
"for hours" and had thus loaded it earlier; this is the first time
com.twc.trader.SupportResistanceDialog$1 has been called for.  (It's
possible for a class to be loaded, discarded, and re-loaded, but
since you say you're doing no ClassLoader trickery that seems fairly
unlikely.)  I think you should focus your attention on the signing of
this seldom-used nested class, and see if that turns up anything of
interest.  At the very least, knowing the particular class that's
involved may help you reproduce the problem with less waiting around.

     I don't know whether it makes a difference, but the troublesome
class is being loaded from the network, not from a local source.  Maybe
you've got a mismatched mixture of old, cached classes with fresh
somewhere-over-the-network classes?  It might be helpful to turn on the
JVM's trace of class-loading activity, and see if anything's weird.

     Good luck!

Okay, thanks for your response. Take it easy, yes it's a GUI driven
application but it does run unattended usually overnight, and runs
24x7 whether operator is present or not. Now, I admit I've only seen
the problem when clicking a button, or when an action listener wants
to do something, like put up that dialog. That's true.

Perhaps I don't understand the concept of "signing". I sign the jars,
and is that not sufficient? There are plenty of times the app pulls
up this particular dialog just fine. And other times it does not.
This inconsistency is the issue here. Also, I've seen the Security
Warning on other action listeners as well. Since the problem is
intermittent and difficult to reproduce, I can't say whether the
particular function was used in the past or not.

I am not aware of any network-loaded classes, and that's a great
suggestion. The application does do RMI amongst copies of itself but
I don't believe that's the problem. The intent is that it can run
standalone, without an internet connection, on an isolated machine as
well as during live online trading, of course.

I will see whether for some weird reason attempts are being made to
load classes over the network. I'll investigate how you came to this
conclusion and maybe there is something weird going on here...

Here's the jnlp used to run the thing, which resides on a webserver,
and it uses 5 locally cached jars, plus the installed JRE of course,
which is not the Client VM, but the Sun Java Server VM for high
performance.

Is there something in this jnlp which would trigger class loading over
the network? That's a subtlety I hadn't thought of....

<?xml version="1.0" encoding="UTF-8" ?>
<jnlp spec="1.0+" codebase="http://FutureScalper.com/[location
removed]/serverbeta_ta" href="FutureScalperServerBeta_ta.jnlp">

<information>
<title>FutureScalper Server TA BETA</title>
<vendor>FutureScalper.com</vendor>
<description>FutureScalper Server TA BETA</description>
<homepage href="http://FutureScalper.com/[location removed]/
serverbeta_ta" />
<offline-allowed />
</information>

<security>
<all-permissions />
</security>

<resources>
<j2se version="1.6.0+" java-vm-args=" -server -
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1TimeSliceMS=40 -
-XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled
-
-XX:GCPauseIntervalMillis=250 -
-XX:ThreadStackSize=128 -XX:CompileThreshold=20 -
-XX:CICompilerCount=4 -XX:+UseBiasedLocking -
-XX:+AggressiveHeap -XX:+ForceTimeHighResolution -
-XX:+RelaxAccessControlCheck -XX:-TieredCompilation -
-XX:MaxInlineSize=256000 -Xverify:none -XX:FreqInlineSize=256000 -XX:-
DontCompileHugeMethods -
-XX:+UseFastAccessorMethods -Xss128k -Xms370m -Xmx370m -Xbatch -
Xnoclassgc -
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel
--Dswing.metalTheme=steel -
-Ddeployment.security.mixcode=DISABLE -
-Duser.timezone=America/New_York -Duser.language=en -Duser.region=US /
<property name="sun.java2d.noddraw" value="true" />
<property name="sun.java2d.d3d" value="false" />
<property name="java.rmi.server.hostname" value="127.0.0.1" />
<property name="deployment.security.mixcode" value="DISABLE" />

<jar href="sFutureScalperSounds.jar" download="eager" main="false" / <jar href="sFutureScalperContracts.jar" download="eager"
main="false" />
<jar href="sFutureScalperAuth.jar" download="eager" main="false" / </resources>

<application-desc main-class="com.twc.trader.FutureScalper">
<argument>command-line-argument</argument>
</application-desc>

</jnlp>

 

[FutureScalper]

[...]
      Also, the app doesn't merely "run for hours" and suddenly hit
trouble while doing the same things it's been doing all along.  The
JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
class, which it wouldn't be doing if it had been using that class
"for hours" and had thus loaded it earlier; this is the first time
com.twc.trader.SupportResistanceDialog$1 has been called for.  (It's
possible for a class to be loaded, discarded, and re-loaded, but
since you say you're doing no ClassLoader trickery that seems fairly
unlikely.)  I think you should focus your attention on the signing of
this seldom-used nested class, and see if that turns up anything of
interest.  At the very least, knowing the particular class that's
involved may help you reproduce the problem with less waiting around.

[...] There are plenty of times the app pulls
up this particular dialog just fine.  And other times it does not.
This inconsistency is the issue here.  Also, I've seen the Security
Warning on other action listeners as well.  Since the problem is
intermittent and difficult to reproduce, I can't say whether the
particular function was used in the past or not.

     Function, schmunction: The stack trace you provided shows that
the trouble is in loading com.twc.trader.SupportResistanceDialog$1.
The JVM wouldn't be loading the class if it had already been loaded
previously (unless you're doing something odd with ClassLoaders, which
you say you're not), so this is the first time the class has been used.
Find out what the class is (from its name, it looks like a nested class
within com.twc.trader.SupportResistanceDialog), find out what action
causes it to be loaded, and you'll be well on the way to understanding
the chain of events that leads to the failure.  That's not a solution
in and of itself, but you'll at least have a way to provoke failures
"more reliably."

I am not aware of any network-loaded classes, [...]

I will see whether for some weird reason attempts are being made to
load classes over the network.  I'll investigate how you came to this
conclusion and maybe there is something weird going on here...

     See those java.net.URLClassLoader methods in the stack trace?

     Let me narrow it down a little more for you: The class gets loaded
while you're in com.twc.trader.SupportResistanceDialog.<init>, that is,
while you're constructing an instance of SupportResistanceDialog.  I
can't tell how many constructors this class has nor which of them is
running, but at least one of them uses the nested class and somebody
tries to load the nested class from the network.

Eric, there is NOTHING which should provoke classes being loaded "from
the network".

All JARs are local, all loads in this case are "ordinary"
instantiations.

Just because "...URL..." is in the name of the method doesn't mean the
"network" is involved.

ANYWAY, what part of "deployment.security.mixcode=DISABLE" does the
Java runtime NOT understand ????

To me, it doesn't go any further than that. If deployment.config is
correctly set, and mandates deployment.properties, and it contains
"deployment.security.mixcode=DISABLE" then it should be GAME OVER for
mixed code Security Warnings.

What more is there to this issue? I should NOT be receiving the mixed
code Security Warning.

Under what circumstances should this ever happen, given the
specifications for the property "deployment.security.mixcode=DISABLE".

Please explain it to me; and in the meantime, I have to freeze at Sun
Java 6 Update 17 until what I strongly suspect is a bug, is resolved.

The class in question is loaded 99.9% of the time without issue. I
believe the VM "reverts" erroneously to mixed code checking at
runtime, as I've had issues with other classes being loaded, also as a
result of a GUI activity. Again, I'm just asking why the
inconsistency? If it's NOT entitled to be loaded, then it should
NEVER load, or am I being naive here?

I am very appreciative of your replies.

 

[Eric Sosman]

[...]
Just because "...URL..." is in the name of the method doesn't mean the
"network" is involved.

Sorry; my mistake. I keep forgetting that "URL" encompasses
a lot more things than network protocols.

The class in question is loaded 99.9% of the time without issue.

Why do you believe so? Why do you believe this class, unlike
practically all other classes, is loaded more than once? Have you
traced the JVM's loading of classes? Have you even traced the
loading of this one particular class, perhaps by putting a logging
call in its static initialization code? Have you even determined
what the class *is* -- yes, we know its synthetic name, but have
you figured out which bit of source code it corresponds to?

You keep rending your garments and tearing your hair about the
injustice of a SecurityException, but I've seen nothing to indicate
you're doing anything but the tearing and rending -- except, maybe,
the "99.9%" figure, but I suspect you just plucked that one from the
air. How did you measure it? What experiments have you tried?

 

[FutureScalper]

[...]
Just because "...URL..." is in the name of the method doesn't mean the
"network" is involved.

     Sorry; my mistake.  I keep forgetting that "URL" encompasses
a lot more things than network protocols.

The class in question is loaded 99.9% of the time without issue.

     Why do you believe so?  Why do you believe this class, unlike
practically all other classes, is loaded more than once?  Have you
traced the JVM's loading of classes?  Have you even traced the
loading of this one particular class, perhaps by putting a logging
call in its static initialization code?  Have you even determined
what the class *is* -- yes, we know its synthetic name, but have
you figured out which bit of source code it corresponds to?

     You keep rending your garments and tearing your hair about the
injustice of a SecurityException, but I've seen nothing to indicate
you're doing anything but the tearing and rending -- except, maybe,
the "99.9%" figure, but I suspect you just plucked that one from the
air.  How did you measure it?  What experiments have you tried?

You've really got an attitude. Look, the class is MY code, it's an
ordinary JDialog and it's loaded only once. It loads fine, and I
repeat 99.9% of the time. I don't care of that initial load is first
in the session or a couple of hours later.

The only point here is that it should NEVER load if it's in violation
of the mixed code restriction, not sometimes.

And the mixed code restriction is switched off. Why doesn't that
impress you?

Never mind whether I've traced class loading... The point is that the
Security Warning intermittent issue is probably a BUG and I submitted
a bug report to Sun/Oracle on this.

 

[Eric Sosman]

You've really got an attitude.

Yes, I've got an attitude. My attitude is that your shirty
back-sass justifies me in tripling my fees for trying to help.

Look, the class is MY code, it's an
ordinary JDialog and it's loaded only once. It loads fine, and I
repeat 99.9% of the time.

So you've actually recorded at least a thousand successful
class loadings with no more than one failure? R-i-i-g-h-t.

Never mind whether I've traced class loading...

I think you have not, and that you're just sulking and making
excuses (and making up numbers). Listen, O Victim, it may in fact
be true that you have encountered a bug. But if you want justice
you need to do more than lie around complaining about it: You've
got to make a case, gather some evidence, investigate, do something
other than sit there in a tear-soaked passive wretchedness. And
you certainly need to stop abusing the passers-by who offer alms.

 

[Lew]

Don't quote sigs.

You've really got an attitude. Look, the class is MY code, it's an

He's got the attitude called "telling the truth".

The evidence strongly supports what Eric told you. The person disregarding
that evidence and resorting to ad hominem remarks is the one with the attitude.

ordinary JDialog and it's loaded only once. It loads fine, and I
repeat 99.9% of the time. I don't care of that initial load is first
in the session or a couple of hours later.

But the stack trace shows that the error occurs during the load of the nested
class to which Eric pointed you, all your shouting notwithstanding.

The only point here is that it should NEVER load if it's in violation
of the mixed code restriction, not sometimes.

And the mixed code restriction is switched off. Why doesn't that
impress you?

Probably because the evidence favors what he said, not what you said.

Never mind whether I've traced class loading... The point is that the

Never mind tracking down the real reason for the problem ...

Security Warning intermittent issue is probably a BUG and I submitted
a bug report to Sun/Oracle on this.

Oh, it's a "BUG" all right, just not in Sun's code.

 

[tackline]

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
class "com.twc.trader.SupportResistanceDialog$1"'s signer information
does not match signer information of other classes in the same package
        at java.lang.ClassLoader.checkCerts(Unknown Source)

This security check dates back over a decade. This exception may now
show up now because of the mixed code fix or some other change in
6u18/6u19/6u20. It's even possible that it's just a race condition
that has been disturbed.

Tom Hawtin