[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cross-project-issues-dev] ACTION REQUIRED: Houston We Have a Problem
|
Recent versions of Java, including the most recent Java 17
release, now consider some jar-signed bundles to be unsigned.
This affects all bundles and features signed between January 1,
2019 and April 14, 2022 with the Eclipse certificate available at
that time.
This is a very long list with many affected projects:
https://download.eclipse.org/oomph/archive/reports-extra/staging-2022-12/download.eclipse.org/staging/2022-12/index.html
The Platform has resigned their problematic bundles already:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/661
Orbit too has resigned the problematic bundles:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=581039
But the Orbit repo with the resigned bundles is NOT the
one used by the Platform for their M3 contribution and is not the
one you/we should be using for M3 which is this one:
https://download.eclipse.org/tools/orbit/downloads/drops/S20221109014815/repository
These projects need to do new builds:
- org.eclipse.acceleo
- org.eclipse.bpmn2
- org.eclipse.dltk
- org.eclipse.ecf
- org.eclipse.eef
- org.eclipse.emf.edapt
- org.eclipse.emf.parsley
- org.eclipse.fx
- org.eclipse.gmf
- org.eclipse.mylyn
- org.eclipse.uml2
You should ensure that the qualifiers
of your bundles and features are newer than 2021-04,
so that you don't have two the "same artifacts" but with different
signatures, which is especially important if you are doing
baseline replacement in your build. I can help test your
repository if you need help. Please reach out to me.
Everyone needs to ensure that
they consume from the next RC1 version of Orbit,
otherwise we are likely to end up with massive duplicate Orbit
bundles and that is likely to cause problems.
I hope someone from Mylyn is paying attention!
https://bugs.eclipse.org/bugs/show_bug.cgi?id=581029
________________________________________________
Meanwhile, I'm trying to enable PGP signing of the bundles and
features with this poor certificates to "repair" them. But,
Tycho does appear to detect that a signature will be ignored,
provides no way to specify how to treat artifacts that already
have a PGP signature (it actually produces duplicate properties in
the artifacts.xml), and it appears the PGP signatures for features
are invalid, so I'm not sure I'll be 100% successful in finding a
workaround. The following might be the best I can do on your
behalf unless the PGP feature signing issue is fixed:
https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index.html
Note that in this scenario, I am adding the sim-bot PGP
key/signature in addition to the key/signature already present
from the project. So all PGP-signed bundles will generally have
two PGP signatures, and in this exceptional case, the bundle is
jar-signed and has two PGP signatures:
https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index/bcpg_1.72.0.html
With PGP-signed features, p2 fails to validate them making them
impossible to download/install, so in this case the cure is worse
than the disease:
https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg-bad/download.eclipse.org/staging/2022-12-gpg-bad/index/org.eclipse.acceleo.equinox.launcher.feature.jar_3.7.11.202102190929.html
Perhaps this issue can be fixed in the coming days...
Regards,
Ed