Problems about mixing signed and unsigned code in the same package

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 lik开发者_开发百科e "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.

---

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.