Java 7u4 webstart安全性异常：类与信任级别不匹配

我们开始注意到,使用 Java 7(特别是更新4),我们的所有用户都开始使用我们的Webstart应用程序看到这一点：

[14:42:58,422] AWT-EventQueue-0(DEBUG) java.lang.SecurityException: class "CLASSNAME" does not match trust level of other classes in the same package
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader$1.run(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.security.AccessController.doPrivileged(Native Method)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.net.URLClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)
[14:42:58,422] AWT-EventQueue-0(DEBUG) at java.lang.ClassLoader.loadClass(Unknown Source)...More

其中CLASSNAME =几乎每个类都在应用程序执行中的几个罐子中的随机点,打破了几个行为.
如果我们的用户使用Java 6,他们没有问题！只是7(更新4).
我们签署所有的罐子,主要的应用罐子和它的库罐子.即启动我们的webstart应用程序的用户看到蓝色盾牌而不是黄色或红色.

这显然是一个问题,因为用户现在更频繁地升级到Java 7.
我试图强制我们的应用程序在用户计算机上使用Java 6,使用以前的安装(工作),或者安装一个新的….使用j2se version =“1.6”标记围绕资源,但这会导致它自己的可能最好进入自己的线程(auto-jre-installation部分)的问题.

Oracle是否通过Java 7u4破坏了Webstart安全性？如何解决此securityexception问题？

解决方法

只是jarsigners hack签入的原始作者.我被另一个开发人员引导到这里,我最初与他分享了黑客攻击.

基于他对此的持续调查,您需要添加以下内容来调用hack

callNoArgMethod("getSigningData",jar);
makeHardLink("signingDataRef",jar);

callNoArgMethod("getManifest",jar);
makeHardLink("manRef",jar,n);

清单调用不是此帖的解决方案的一部分.在创建验收测试以重现问题时,会找到它们.

基于这个新信息,我们改变了我们的方法,我们现在使用反射来调用所有“get”方法(如果没有填充,则需要调用get方法来初始填充软引用)

然后反思地发现CachedJarFile类中的所有软引用并为它们创建硬链接.

只要CachedJarFile保持不变并且黑客的基本前提保持正确,这就可以在未来证明来自其他内部重命名/重构的解决方案. (即：对软参考进行软参考.