JNLP：在签名代码中加载未签名代码

我们在通过Java webstart的混合代码错误时遇到困难。总之，我们有我们的主要JNLP文件，我们已经签署了它直接加载的所有代码。我们已将全部权限选项添加到主JNLP。它加载的主类也来自签名的jar。JNLP：在签名代码中加载未签名代码

当主类开始时，它引发了一些需要加载一些从JNLP B中取出的未签名资源的东西。没有任何JNLP B的资源被签名，并且它们不需要任何特殊权限。

所有已签名的代码都是基于Oracle的混合代码文档进行设置的，并且在签名之前已经将jar文件的清单设置为“Trusted-Library：true”。

当未签名代码试图通过签名代码，我们得到一个类未找到错误，像这样被加载：

java.lang.reflect.InvocationTargetException 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
at java.lang.reflect.Method.invoke(Unknown Source) 
at com.sun.javaws.Launcher.executeApplication(Unknown Source) 
at com.sun.javaws.Launcher.executeMainClass(Unknown Source) 
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) 
at com.sun.javaws.Launcher.run(Unknown Source) 
at java.lang.Thread.run(Unknown Source) 

    Caused by: java.lang.NoClassDefFoundError: org/some/external/package/that/is/not/signed 
at org.our.signed.package.main(Main.java:87) 
... 9 more 

    Caused by: java.lang.ClassNotFoundException: org.some.external.package.that.is.not.signed 
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) 
... 10 more

这里是在JNLP的场景：

JNLP答：（总结）

<jnlp spec="1.5+" codebase="...." href="......"> 
    <information> 
    ...etc 
    </information> 
    <security> 
    <all-permissions/> 
    </security> 
    <resources> 
     <j2se version="1.6+" initial-heap-size="80m" max-heap-size="256m" href="http://java.sun.com/products/autodl/j2se"/> 
     <jar href="signedJar_1.jar" download="eager" main="true"/> 
     <jar href="signedJar_2.jar" download="eager" main="false"/> 
     <extension name="unsigned_ext" href="unsigned.jnlp"/> 
    </resources> 
    <application-desc main-class="(FROM SIGNED CLASS in signedJar_1.jar)"/> 
</jnlp>

JNLP B（所述unsigned.jnlp装载机）

<jnlp spec="1.5+" codebase="....." href="......"> 
    <information> 
    ...etc 
    </information> 
    <resources> 
    <jar href="unsigned.jar"/> 
    </resources> 
    <component-desc/> 
</jnlp>

我们已经注意到安全异常工作正常，因为如果我们将未签名的jar移动到具有所有权限并已签名jar的JNLP中，我们就会得到预期的安全异常，即Java不会让我们混合与Trusted-Library签名的代码：真实和未签名的代码，没有清单属性。

想法？类加载器无法从未签名的代码中找到java文件吗？是否有什么特别的东西让我们错过了允许签名代码运行未签名的代码？我只看到了人们遇到问题的情况，即获取未签名的代码来运行已签名的代码，这是我能理解的。

来源

2012-04-19 rmmeans

可信库加载器是（可能不可信的）小应用程序类加载器的父类（在类加载器委托的意义上）。把它看作是引导类加载器。所以不受信任的类可以链接到受信任的库类，但反之亦然。不用担心改变清单和使用WebStart，你可以试试这个东西，通过将-Xbootclasspath/a:和你的不可信任的类加入-classpath（这是该特性在实现之前被试用过）。

JNLPAppletLauncher是如何让trusted-libraries调用applet代码的一个例子。小程序类加载器可以通过Thread.currentThread().getContextClassLoader()获得，这只是从那里反思。编写安全可信的库代码非常棘手。请记住，你不能相信不受信任的代码。

来源

2012-04-19 21:46:59

所以你说可信的代码根本不能运行不可信的代码？例如，我们的应用程序是一个通过网络启动加载的内部CRM（无小程序）。我们的CRM有时需要访问本地文件系统（签署/全部烫发的原因）。我们的客户关系管理系统还需要一些其他的罐子，比如用于UI的swingx.jar，帮助设置如jhall.jar等。那么我们的可信代码就无法访问这些其他罐子？我们是否必须将我们的可信任功能放入自己的罐子中，并仅签署这些功能，让我们的主要核心不受信任，以便我们还可以使用不可信的罐子？ – rmmeans 2012-04-19 22:05:06

（Applet和JNLPWebStart应用程序/小应用程序基本上是可以互换的。）不可信赖的代码依赖于不可信代码的行为。您可以将受信任的代码作为库，但您需要非常小心，在其上执行的任何操作都是安全的。你不能只有一种方法，比如说，将某些数据保存到指定的文件名（并保持安全）。 – 2012-04-19 22:38:05

@ TomHawtin-tackline如果沙盒扩展中的代码是数字签名的，它会导致问题吗？ – 2012-04-20 02:25:34

JNLP：在签名代码中加载未签名代码

回答

相关问题