T
Thomas Richter
Hi folks,
as the subject says, we have currently some problem mixing our own code,
in a jar file, with code coming from other sources. Clearly, a classic,
and definitely not new:
http://download.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html
What we get is the classical security exception saying "class 'XYZ' does
not match trust level of other classes in the same package".
That's all understood and clear. However, the following bewilders me and
I wonder if anyone could come up with an explanation:
I do understand the issue if several jar's are deployed, signed by
different entities, and thus the java classloader can check where each
class came from and by whom it was signed (or whether it was signed).
Our applet needs to be signed since it needs to pull information over
the net via http.
However, now we tried the following: Extract all the jars we need to
load, erase the manifest file, re-package the resulting directory in a
jar, and sign the jar. I erroneously believed that might fix the issue
since now all classes are signed by a single entity, hence no conflicts
between signed and unsigned classes since the latter ones do not exist.
Apparently, I am wrong. The exception still appears. I still wonder why.
Where is the information on which classes are signed and which aren't
actually stored if not in the manifest? How can I sign the classes (not
the jar!) consistently such that I have only signed classes in the jar,
signed by one and the same and only entity?
Thanks for any help,
Thomas
as the subject says, we have currently some problem mixing our own code,
in a jar file, with code coming from other sources. Clearly, a classic,
and definitely not new:
http://download.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html
What we get is the classical security exception saying "class 'XYZ' does
not match trust level of other classes in the same package".
That's all understood and clear. However, the following bewilders me and
I wonder if anyone could come up with an explanation:
I do understand the issue if several jar's are deployed, signed by
different entities, and thus the java classloader can check where each
class came from and by whom it was signed (or whether it was signed).
Our applet needs to be signed since it needs to pull information over
the net via http.
However, now we tried the following: Extract all the jars we need to
load, erase the manifest file, re-package the resulting directory in a
jar, and sign the jar. I erroneously believed that might fix the issue
since now all classes are signed by a single entity, hence no conflicts
between signed and unsigned classes since the latter ones do not exist.
Apparently, I am wrong. The exception still appears. I still wonder why.
Where is the information on which classes are signed and which aren't
actually stored if not in the manifest? How can I sign the classes (not
the jar!) consistently such that I have only signed classes in the jar,
signed by one and the same and only entity?
Thanks for any help,
Thomas