Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] [platform-dev] Unsigned Content?


On Fri, Dec 17, 2021 at 10:11 AM Ed Merks <ed.merks@xxxxxxxxx> wrote:

Comments below.

On 17.12.2021 07:46, Aleksandar Kurtakov wrote:


On Fri, Dec 17, 2021 at 8:01 AM Ed Merks <ed.merks@xxxxxxxxx> 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!
That appears to be the case given these particular IUs are not on the current train.
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 .

A proof of concept is arguably useful. 

Here is what happens when the installer tries to install org.mockito.mockito-core into a Platform SDK IDE:

java.lang.NullPointerException
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.buildPGPTrustore(CertificateChecker.java:311)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:63)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker$1.get(CertificateChecker.java:1)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.checkCertificates(CertificateChecker.java:126)
    at org.eclipse.equinox.internal.p2.engine.phases.CertificateChecker.start(CertificateChecker.java:83)
    at org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(CheckTrust.java:63)
    at org.eclipse.equinox.internal.p2.engine.Phase.postPerform(Phase.java:254)
    at org.eclipse.equinox.internal.p2.engine.Phase.perform(Phase.java:105)
    at org.eclipse.equinox.internal.p2.engine.PhaseSet.perform(PhaseSet.java:50)
    at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:80)
    at org.eclipse.equinox.internal.p2.engine.Engine.perform(Engine.java:48)
    at org.eclipse.equinox.internal.provisional.p2.director.PlanExecutionHelper.executePlan(PlanExecutionHelper.java:46)
    at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$3.commit(ProfileTransactionImpl.java:549)
    at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:345)
    at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:905)
    at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3851)
    at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3779)
    at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3760)
    at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3638)
    at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:600)
    at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:727)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Why?  Because org.eclipse.equinox.internal.p2.engine.phases.CheckTrust.completePhase(IProgressMonitor, IProfile, Map<String, Object>) knows the profile, but the certificate checker doesn't know to check that profile but rather checks the self profile.  I imagine the p2 director will have such problems too, or perhaps it will not fail but also might not actually check the correct profile...

If p2.director fails please open a bug about it and it will be handled with priority.

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.
I sympathize fully with the endless work of getting things done primarily for the benefit of others.  I wonder though if n projects have to duplicate the effort n times if that will be n times the work.  Also, might we end up with n versions of each such bundle?  That's not a problem for the platform, but it's problem for SimRel and for the community at large.  The Platform PMC is of course not obligated to care.
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.
The community with which I'm familiar tended to build consensus around decisions.  In any case, I can relate to being tired.  It has been impossible to find time to look into the evolving new approach.  (The log4j thing was of course endless fun too.)
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 path the Platform PMC has chosen to take is effectively the first one.  Dismissing the third option might have been done only after communicating with the community before hand...

https://www.eclipse.org/lists/platform-dev/msg02725.html - Exactly ZERO interest for someone to handle the easy daily but time consuming tasks and EVEN LESS to help improve the current situation. And things got worse since then - there are at least 2 more JVM versions to care about, multiple major changes in OSes used, plethora of security issues and so on. So yes we have chosen the path but it's based on community involvement not because we woke up that way.
Before anyone asks why we haven't asked more broadly - producing eclipse platform build requires understanding of different ws/os/arch combos supported, good maven knowledge and good understanding of the interdependencies of the release process and components.
Of course everyone can help by just bulding locally the whole platform.releng.aggregator and picking even the smallest inconvenience or helping with anything at https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse%20Project&component=Releng&order=Importance&product=Platform&query_format=advanced (note bug triaging aka identifying that a but still exists and make sense is valuable learning experience and will help out enormously too).
 
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.
 
It doesn't appear there is really much of discussion to be had though...

If we wanted to go without discussions - Eclipse Platform would have updated content that's in later contributed to simrel already! But discussions without actions is not something that can continue endlessly. So what we do is lay the groundwork in the way current people can continue delivering and give some time  for others to decide whether they jump in significantly and immediately or take what is technically possible to deliver from current people involved.
 

_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev


--
Aleksandar Kurtakov
Red Hat Eclipse Team

Back to the top