search

eclipse-platform / eclipse.platform.releng.aggregator

Aggregated repository for Eclipse Java IDE
https://www.eclipse.org/eclipse/
Eclipse Public License 2.0
30 stars 74 forks source link

Split packages have different signatures #2335

Closed kysmith-csg closed 3 weeks ago

kysmith-csg commented 3 weeks ago

For licensing reasons, we must run an obfuscator in our code which goes through the bytecode of all our dependencies. After updating to the latest Eclipse 4.33 I am getting the following error:

java.lang.SecurityException: class "org.eclipse.jface.text.TextViewer"'s signer information does not match signer information of other classes in the same package
        at java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1173)
        at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:917)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1025)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
        at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
        at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
        at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
        at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
        at java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:872)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
        at java.base/java.lang.Class.getDeclaredFields0(Native Method)
        at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3473)
        at java.base/java.lang.Class.getDeclaredFields(Class.java:2542)

This seems related to the discussion here: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2044.

The bundle org.eclipse.text hasn't had an update since the previous release 4.32 (build qualifier is 20240524), but org.eclipse.jface.text has (qualifier 20240816). I think this might've just been the first error that happened, but I expect that the same error would happen with the other split packages.

Is there anything we can do to fix this? Otherwise it seems we won't be able to update to the latest Eclipse.

merks commented 3 weeks ago

I think you're kind of hosed. I was not keeping track that we have yet more split packages than I was considering, being focused mostly on the core runtime parts.

We really need some type of automated test for split-packages-with-different-signatures. 😭 But of course who wants to work on that or pay for that?

mickaelistria commented 3 weeks ago

One possible solution is to just abandon jarsigner in Platform and go fully PGP.

akurtakov commented 3 weeks ago

One possible solution is to just abandon jarsigner in Platform and go fully PGP.

I can only second that. Jarsigner is causing more trouble than it's worth.

merks commented 3 weeks ago

A preliminary test suggests that the following packages are split across bundles with different signing certificates in the current 4.34 I-builds:

It's easy enough to force a new qualifier which forces a new signature. But when we publish to Maven Central the minor version needs to be incremented (different from what's already been published before) in order to publish a new version.

merks commented 3 weeks ago

There are now generated reports:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.34-I-builds/index.html

with details about split packages with difference signatures:

image

image

There are also junit test results:

Each test result provides details about the IUs and the certificates involved:

image

Now we will need to bump versions to eliminate the problems.

Going forward, we will detect new problems within a day, i.e., long before we publish to Maven Central.

HannesWell commented 3 weeks ago

There are also junit test results:

* https://ci.eclipse.org/oomph/job/repository-analyzer/lastCompletedBuild/testReport/

* https://ci.eclipse.org/oomph/job/repository-analyzer/lastCompletedBuild/testReport/eclipse.updates._4_34_I_builds.I20240912_2100/

Each test result provides details about the IUs and the certificates involved:

Thank you Ed for this!

Ideally this test would be added e.g. to the platform-releng-aggregator repository and makes the I-build fail if there are inconsistent signatures. Maybe the report could be created and evaluated as part of the aggregation of the SDK p2-repo?

Otherwise I fear you'll be the only one paying attention to those tests and and taking care of failures, because most of the SDK committers won't have a look at Oomph's tests. But if the I-build fails the audience should be much wider.

merks commented 3 weeks ago

This job does the work:

https://ci.eclipse.org/oomph/job/repository-analyzer

Any ci instance could define their own job for doing the work, e.g., like SimRel does:

https://ci.eclipse.org/simrel/job/simrel.oomph.repository-analyzer.test/

It's easy to give/get attention for failure regardless of where the job is hosted:

image

E.g., for this job I make sure that it gets my personal attention if there is a failure:

https://ci.eclipse.org/releng/view/Publish%20to%20Maven/job/CBIaggregator

image

The application is primarily focused on generating the report, with junit support added later, but it could be tailored only to generate junit test results...

I think with the increments done now, we're mostly done until the certificate renews in July of next year, except for this split triplet:

image

merks commented 3 weeks ago

The latest nightly build is free of split packages with inconsistent signatures:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.34-I-builds/https___download.eclipse.org_eclipse_updates_4.34-I-builds_I20240915-1800.html

For what it's worth, SNAPSHOT publishing is done nightly:

https://repo.eclipse.org/content/repositories/eclipse-snapshots/

The tests should ensure that a recurrence of this problem will be noticed with 24 hours and will be fixed before publishing to Maven Central.