On Fri, Dec 17, 2021 at 8:01 AM Ed Merks <ed.me...@gmail.com> wrote: > Has the platform decided to bypass Orbit to produce IUs directly from > some other sources? I'm not sure how the multiple versions of such IUs > on the release train will be (or even can be) coordinated across > projects if the general new approach is that each project produces such > things purely for its own purpose from whatever sources it deems fit. > > Also, the artifacts are not signed, which is the reason that I noticed: > > > https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.23-I-builds/index.html > > Note that once an unsigned version of some specific artifact ID is out > there is the wild (in someone's bundle pool), it's extremely hard to > stamp it out unless a new version with a new artifact ID is created to > supersede it. > > Perhaps the platform has decided that PGP signatures are now deemed to > be fully secure and fully feature complete such that signatures are > obsolete? This is not the expectation I have based Planning Council > discussions. >
Platform is not contributing these to release train so no issue for release train for now! The feature org.eclipse.test relies on PGP on purpose as this is our proof and example how PGP works and is on par with jarsigner as far as signing requirements for third party dependencies are considered https://github.com/eclipse-cbi/best-practices/blob/main/software-supply-chain/osssc-best-practices.md#securing-third-party-artifacts . Updating mockito and friends to newer versions so they work with latest Java versions is a task we couldn't have completed if we had gone through Orbit as this literally doubles the work involved. This was a topic for next Planning Council meeting but as it's already bringed here: Yes, Eclipse PMC has decided that we are going with PGP signatures and it's fullfilling the given requirements ( https://wiki.eclipse.org/Eclipse/PMC#Meeting_Minutes). There is just not enough manpower to keep releng uptodate and fix bugs at the same time. So from now on things like Jetty updates and other third party updates will go with PGP signing only from Eclipse TLP. It's not a decision taken lightly - it's total exhaustion amongst people doing that work and lack of interest from others to heavily engage in either sharing the burden of the releng process or at least look into the new approach and point issues in it. So the possible paths I see are: * Simrel accepts PGP signatures * Simrel stays with old Platform that doesn't contain third party PGP signed dependencies * Someone steps up to do all the needed work in the old way * Someone points how a real exploit with PGP signing but can't happen with jarsigning The topic is something I have planned to bring to the next Planning Council meeting in January. Eclipse Platform doesn't plan to push any third party updates for content in Simrel for limited period to give some time for Planning Council to discuss and decide. I seriously wanted to delay this discussion after Christmas to not interrupt the discussions during vacations, which already started or start today for quite a few people including me. > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > On behalf of Eclipse PMC -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
