7

我们开始注意到使用 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.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 = 应用程序执行中几个 jar 中随机点的几乎每个类，破坏了几种行为。如果我们的用户使用 Java 6，他们没有问题！只有 7 个（更新 4）。我们对所有的 jar 进行签名，包括主应用程序 jar 和库 jar。ie 启动我们的 webstart 应用程序的用户看到蓝色盾牌而不是黄色或红色。

这显然是一个问题，因为用户现在更频繁地升级到 Java 7。我试图通过使用以前的安装（工作）或安装新的来强制我们的应用程序在用户机器上使用 Java 6....在资源周围使用 j2se version="1.6" 标记，但这会导致它自己的问题，最好将其放入它自己的线程（auto-jre-installation 部分）。

Oracle 是否使用 Java 7u4 破坏了 Webstart 安全性？如何解决此安全异常问题？

4

5 回答 5

6

我在 1.7.07 中遇到了同样的问题：我的 webstart 应用程序在加载类时随机失败，并显示相同的错误消息。我在这个页面上找到了一个有趣的解决方法oracle forums。最后一个答案描述了该问题的解决方法（Java 6） - 对 jar 签名的引用被保留为软引用，这些可能被垃圾收集，这会导致错误消息。这可以通过一些额外的行用于 Java 7

// Java 1.7
callNoArgMethod("getSigningData", jar);
makeHardLink("signingDataRef", jar);
于 2012-11-22T13:41:57.483 回答
3

只是 jarsigners hack 签入的原始作者。我是由另一个开发人员指导的，我最初与他分享了 hack。

根据他对此的持续调查，您需要将以下内容添加到对 hack 的调用中

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

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

清单调用不是本文解决方案的一部分。它们是在创建验收测试以重现问题时发现的。

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

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

只要 CachedJarFile 保持在原位并且 hack 的基本前提保持不变，这应该会在未来证明进一步内部重命名/重构的解决方案。（即：将软引用变为硬引用。

于 2013-02-18T23:48:35.680 回答
2

我想你可能会遇到这个错误。

错误状态表明已在 7u4 中提供了修复。但这与你所说的并不相符。也许“修复”会中断....

与此同时，“squaat”对该错误的评论提到了可能的解决方法。例如，增加初始堆大小和/或使用预加载器强制一些 JAR 提前加载。

于 2012-06-05T22:29:27.217 回答
1

更新到 JRE 8 更新 91 后，我遇到了同样的问题。在以前的版本 1.6、1.7、1.8 更新 77 中，我的应用程序运行良好。

Oracle 是否重新引入了 JRE 1.6 错误中存在的错误？

我发现的唯一解决方法是从 Java 控制面板禁用混合代码控制。

我修好了它。问题出在我的应用程序使用的库中。罐子里的 MANIFEST.MF 是这样的：

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_07-87 ("Apple Computer, Inc.")
Built-By: wolf

Name: common
Specification-Title: swixml
Specification-Vendor: swixml.org
Specification-Version: 1.6
Implementation-Title: org.swixml
Implementation-Vendor: swixml.org
Implementation-Version: 1.6 beta 1 (#151)

“名称”属性用于此处所述的资源特定条目http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#JAR_Manifest

对此 jar 进行签名时，“名称”条目将被解释为资源，但没有要签名的资源。当应用程序启动时，javaws 发现 MANIFEST.MF 中报告的资源与阻塞应用程序的 jar 中的有效资源不匹配

于 2016-04-20T15:55:31.507 回答
0

我一直在使用 JRE 7u5 处理相同的症状。完全相同的应用程序 web 使用 JRE 6u33 启动时没有问题。

就我而言，问题是由我的扩展 jnlp 文件之一引起的。主 jnlp 文件指定了所有权限安全，而扩展 jnlp 没有声明任何特定的安全要求（只是一个空的安全标记）。

这导致扩展 jar 被加载到沙箱中。显然，Java 7 不接受混合具有不同安全要求的 jar，即使它们都已签名。

通过确保所有扩展 jnlp 文件指定与主 jnlp 文件相同的安全要求，该问题已得到解决。

于 2012-06-26T05:22:58.870 回答