On Mon, Nov 14, 2022 at 2:44 PM Ed Merks <ed.me...@gmail.com> wrote: > 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* > > As probably I'm the last person that has touched dltk, I have to share that the chances for a rebuild are zero as it looks like even the ci is gone https://ci.eclipse.org/dltk . Even if it was there I wouldn't have time for it so if someone is interested to keep it in please state so so I can nominate you to restart the project or it should be removed from simrel.
> > - *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 > > > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
