有关在同一包中混合签名和未签名代码的问题
每个人。据我所知，在JVM中，有些类是经过签名的，而有些类不在同一包下是不允许的。但是这个场景怎么样：我编写了一个 Java Web Start 应用程序，它只有一个像“test.jar”这样的 jar 文件。在 test.jar 中，我编写了一个自定义类加载器，它通过字节码（当然它们没有签名）从网络或硬盘加载类。运行时加载的字节代码中的一些类位于 test.jar 中存在的同一包下。这可以吗？ 另一个问题是 JVM 如何以及在哪里检查哪些类已签名，哪些未签名，以及签名的类是由同一签名者签名的？我认为这些信息应该只是来自jar文件中的MANIFEST.MF文件，对于.class文件的内容，签名和未签名没有区别，对吗？谢谢。我不太了解 JAR 签名机制，但我想要。所以请帮助我，任何反馈都将非常感激。
everyone. As far as I know, in JVM some classes are signed and some are not under the same package is not allowed. But how about this scenario: I write a Java Web Start app which just has one jar file like "test.jar". In test.jar, I write a custom classloader which loads classes by byte code (of course they are not signed) from network or hard disk. Some of the classes from byte code loaded in runtime are under the same package existing in the test.jar. Can this work?
Another question is how and where JVM checks which classes are signed and which are not, and the signed classes are signed by the same signer? I think the information should just come from MANIFEST.MF file in jar file, for the content of .class files, signed and unsigned have no differences, right? Thanks. I'm not very deeply knowing the JAR signing mechanism, but I want. So please help me, any feedback will be very appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
证书验证的实现存在于 java.lang.Classloader 中 Java 运行时的类。它不能仅由自定义类加载器覆盖，因为此过程是作为模板设计模式实现的，证书验证过程是在私有方法中实现的 - checkCerts(String name, CodeSource cs)，通过类的源。覆盖默认行为的一种可能机制是覆盖自定义类加载器中的 DefineClass 方法；在我个人看来，我认为此选项充满风险（由于可能对安全模型产生影响），因此如果要执行此步骤，建议采取充分的预防措施。
显然，运行时中的 Classloader 类是负责验证包使用证书的一致性的类。该实现使用 Map 来存储证书，每个包都有一个证书，任何包的第一个加载的类确定应该用于该包中存在的所有其他类的证书。
如果允许同一包中的不同类拥有不同的签名者，那么我建议了解运行时使用（和构建）的安全模型，因为影响可能不一定仅限于自定义类加载器类。
The implementation for certificate verification exists in the java.lang.Classloader class of the Java runtime. It cannot be overriden merely by a custom classloader, for this process is implemented as a Template design pattern, with the certificate verification process being implemented in a private method - checkCerts(String name, CodeSource cs), going by the source of the class. A possible mechanism to override the default behavior would be to override the defineClass method within the custom Classloader; in my personal opinion, I see this option as fraught with risk (due to possible impacts on the security model), so adequate precaution is advised if this step were to be exercised.
It would be obvious that the Classloader class in the runtime is the class that is responsible for the verification of consistency in using certificates for a package. The implementation uses a Map to store the certificates, one for each package, with the first loaded class of any package determining the certificate that should be used all other classes present in that package.
If one were to allow different classes within the same package to have different signers, then I would advise understanding the security model used (and built) in the runtime, as the impact might not necessarily be restricted to the custom Classloader class alone.