Java Split Package Desaster

With question haveing java-packages split across multiple jars in not a good idea (and the reason JPMS does not allow them) but at least in the Eclipse/OSGi universe they are a common pattern when bigger OSGi-Modules have been split up in multiple smaller ones.

We've an product who is still on Java-8 (don't ask why) so the code uses a fairly old JARs released and signed by the Eclipse Foundation and OSGi-Modules in my case are:

org.eclipse.core.runtime@3.15.0.v20180817-1401
org.eclipse.equinox.common@3.10.600.v20191004-1420

While running with them inside an OSGi application does not cause any problems, running with them in an JUnit-Tests in plain java gave me a java.lang.SecurityException:

java.lang.SecurityException: 
class "org.eclipse.core.runtime.ISafeRunnable"'s signer information does not 
match signer information of other classes in the same package

How can that be? Both JARs are signed by the Eclipse Foundation with the same certificate. Let's take a look what jarsigner says about this.

First org.eclipse.core.runtime:

~/SDKs/java/zulu8.84.0.15-ca-fx-jdk8.0.442-macosx_x64/bin/jarsigner \
 -verbose
 -verify
 ...org.eclipse.core.runtime-3.15.0.v20180817-1401.jar
...
- Signed by "CN="Eclipse.org Foundation, Inc.", OU=IT, O="Eclipse.org Foundation, Inc.", L=Nepean, ST=Ontario, C=CA"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withRSA, 2048-bit key
  Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G2, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Mo Aug 20 12:26:43 UTC 2018
    Timestamp digest algorithm: SHA-256
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

jar verified.

The signer certificate expired on 2021-04-14. However, the JAR will be valid until the timestamp expires on 2028-04-02.

First org.eclipse.equinox.common:

~/SDKs/java/zulu8.84.0.15-ca-fx-jdk8.0.442-macosx_x64/bin/jarsigner \
 -verbose
 -verify
 ...org.eclipse.equinox.registry-3.8.600.v20191017-2055.jar
...
- Signed by "CN="Eclipse.org Foundation, Inc.", OU=IT, O="Eclipse.org Foundation, Inc.", L=Nepean, ST=Ontario, C=CA"
    Digest algorithm: SHA-256
    Signature algorithm: SHA256withRSA, 2048-bit key
  Timestamped by "CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US" on Fr Okt 18 11:40:23 UTC 2019
    Timestamp digest algorithm: SHA-1 (disabled)
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01, include jdk.disabled.namedCurves

So this means that the JVM-Treats the signed JARs differently:

org.eclipse.core.runtime as signed
org.eclipse.equinox.common as unsigned

and hence will fail at runtime.

My (pragmatic) solution: I run the JUnit-Tests in Java8u202 because there both are treated as valid signed.