Re: [platform-dev] Unsigned Content?
(there are two mailing lists in this chain - some emails are not in planning council archive) > The community with which I'm familiar tended to build consensus around decisions. I empathise with the Eclipse PMC, and as I pointed out in various Planning Council and IDE WG calls, Eclipse PMC are a TLP that can do what they want (within EDP, etc). As far as I can tell they have tried to build consensus, but we are 4 months into the process of trying to get consensus on this issue and we remain log jammed. As a reminder, the next step is "Wayne has volunteered to try and put together the document that is digestible by the IDE WG and reviewers." (from https://wiki.eclipse.org/Planning_Council/2021-12-01) If the 2022-03 release ships with Eclipse Platform 4.22, that would be surprising, but not the end of the world. However my understanding is that for Eclipse Platform 4.23 all bundles that are currently in SimRel will continue to be jarsigned anyway. If something has changed in that regard: > So from now on things like Jetty updates and other third party updates will go with PGP signing only from Eclipse TLP. then maybe we have something to hurry us along. Thank you Eclipse PMC for lighting a suitable sized fire under our collective behinds. And finally another reminder "The steering committee is onboard with the general direction of this work. The work looks promising and no plan to change direction." (from 16 Nov IDE WG minutes https://www.eclipse.org/lists/eclipse-ide-wg/msg00114.html) Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Fri, 17 Dec 2021 at 03:45, Mickael Istria wrote: > > > On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: > >> 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) 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... >> > > Such feedback is really welcome. Can you please open a dedicated bug for > this issue and add me as CC ? > > I wonder though if n projects have to duplicate the effort n times if that >> will be n times the work. >> > > The effort of consuming upstream artifacts from Maven is equivalent to the > effort of consuming artifacts from Orbit. So there is no extra effort > involved for consumers, they just change a version in their .target and > that's all. > "Downstream"
Re: [platform-dev] Unsigned Content?
On Fri, 17 Dec 2021 at 12:35, Lars Vogel wrote: > > Mockito releases on > every commit Seriously‽ Wow, Mockito is the new Lucene... ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Unsigned Content?
My RCP clients love the new Maven lib integration. Orbit used to be really really slow with updates. For example, Mockito releases on every commit, replicating this in Orbit would be a huge amount of work. And it feels not as a value add step as in the end the same library is provided. On Fri, Dec 17, 2021 at 10:39 AM Aleksandar Kurtakov wrote: > > > > On Fri, Dec 17, 2021 at 11:27 AM Ed Merks wrote: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=577863 > > > Thanks, that would be a priority after vacation. > >> >> >> On 17.12.2021 09:44, Mickael Istria wrote: >> >> >> >> On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: >>> >>> 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) 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... >> >> >> Such feedback is really welcome. Can you please open a dedicated bug for >> this issue and add me as CC ? >> >>> I wonder though if n projects have to duplicate the effort n times if that >>> will be n times the work. >> >> >> The effort of consuming upstream artifacts from Maven is equivalent to the >> effort of consuming artifacts from Orbit. So there is no extra effort >> involved for consumers, they just change a version in their .target and >> that's all. >> "Downstream" projects can also directly consume bundles provided by their >> "upstream" ones in a plain p2 way. For example, a project that need mockito >> can just take Mockito from Platform instead of Orbit, without playing with >> Maven dependencies. It's actually already a common and efficient: may target >> files don't reference Orbit and pick the libs that's provided by their >> "upstream". >> >>> >>> Also, might we end up with n versions of each such bundle? >> >> >> We already do have N versions of several libs, split across multiple >> repositories (eg some older projects don't rebuild against latest Orbit and >> still include older libs). p2 -during SimRel aggregation or installation on >> user end- does take care of picking the best and tries to avoid multiple >> versions when this can be avoided. >> Consuming libs from Maven instead of Orbit doesn't really change the >> problem/solution in the end. >> >> >>
Re: [platform-dev] Unsigned Content?
On Fri, Dec 17, 2021 at 11:27 AM Ed Merks wrote: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=577863 > Thanks, that would be a priority after vacation. > > On 17.12.2021 09:44, Mickael Istria wrote: > > > > On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: > >> 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) 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... >> > > Such feedback is really welcome. Can you please open a dedicated bug for > this issue and add me as CC ? > > I wonder though if n projects have to duplicate the effort n times if that >> will be n times the work. >> > > The effort of consuming upstream artifacts from Maven is equivalent to the > effort of consuming artifacts from Orbit. So there is no extra effort > involved for consumers, they just change a version in their .target and > that's all. > "Downstream" projects can also directly consume bundles provided by their > "upstream" ones in a plain p2 way. For example, a project that need mockito > can just take Mockito from Platform instead of Orbit, without playing with > Maven dependencies. It's actually already a common and efficient: may > target files don't reference Orbit and pick the libs that's provided by > their "upstream". > > >> Also, might we end up with n versions of each such bundle? >> > > We already do have N versions of several libs, split across multiple > repositories (eg some older projects don't rebuild against latest Orbit and > still include older libs). p2 -during SimRel aggregation or installation on > user end- does take care of picking the best and tries to avoid multiple > versions when this can be avoided. > Consuming libs from Maven instead of Orbit doesn't really change the > problem/solution in the end. > > > ___ > platform-dev mailing listplatform-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > ___ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > -- Aleksandar Kurtakov Red Hat Eclipse Team ___ platform-dev mailing list
Re: [platform-dev] Unsigned Content?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=577863 On 17.12.2021 09:44, Mickael Istria wrote: On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: 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) 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... Such feedback is really welcome. Can you please open a dedicated bug for this issue and add me as CC ? I wonder though if n projects have to duplicate the effort n times if that will be n times the work. The effort of consuming upstream artifacts from Maven is equivalent to the effort of consuming artifacts from Orbit. So there is no extra effort involved for consumers, they just change a version in their .target and that's all. "Downstream" projects can also directly consume bundles provided by their "upstream" ones in a plain p2 way. For example, a project that need mockito can just take Mockito from Platform instead of Orbit, without playing with Maven dependencies. It's actually already a common and efficient: may target files don't reference Orbit and pick the libs that's provided by their "upstream". Also, might we end up with n versions of each such bundle? We already do have N versions of several libs, split across multiple repositories (eg some older projects don't rebuild against latest Orbit and still include older libs). p2 -during SimRel aggregation or installation on user end- does take care of picking the best and tries to avoid multiple versions when this can be avoided. Consuming libs from Maven instead of Orbit doesn't really change the problem/solution in the end. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Unsigned Content?
On Fri, Dec 17, 2021 at 9:11 AM Ed Merks wrote: > 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) 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... > Such feedback is really welcome. Can you please open a dedicated bug for this issue and add me as CC ? I wonder though if n projects have to duplicate the effort n times if that > will be n times the work. > The effort of consuming upstream artifacts from Maven is equivalent to the effort of consuming artifacts from Orbit. So there is no extra effort involved for consumers, they just change a version in their .target and that's all. "Downstream" projects can also directly consume bundles provided by their "upstream" ones in a plain p2 way. For example, a project that need mockito can just take Mockito from Platform instead of Orbit, without playing with Maven dependencies. It's actually already a common and efficient: may target files don't reference Orbit and pick the libs that's provided by their "upstream". > Also, might we end up with n versions of each such bundle? > We already do have N versions of several libs, split across multiple repositories (eg some older projects don't rebuild against latest Orbit and still include older libs). p2 -during SimRel aggregation or installation on user end- does take care of picking the best and tries to avoid multiple versions when this can be avoided. Consuming libs from Maven instead of Orbit doesn't really change the problem/solution in the end. ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
Re: [platform-dev] Unsigned Content?
On Fri, Dec 17, 2021 at 10:11 AM Ed Merks wrote: > Comments below. > On 17.12.2021 07:46, Aleksandar Kurtakov wrote: > > > > On Fri, Dec 17, 2021 at 8:01 AM Ed Merks 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) 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
Re: [platform-dev] Unsigned Content?
Comments below. On 17.12.2021 07:46, Aleksandar Kurtakov wrote: On Fri, Dec 17, 2021 at 8:01 AM Ed Merks 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) 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... 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
Re: [platform-dev] Unsigned Content?
On Fri, Dec 17, 2021 at 8:01 AM Ed Merks 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
Re: [platform-dev] Unsigned Content?
Hi Ed, I assume this is result of changes in this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577522 Am 17. Dezember 2021 07:01:39 MEZ schrieb Ed Merks : >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-dev mailing list >platform-dev@eclipse.org >To unsubscribe from this list, visit >https://www.eclipse.org/mailman/listinfo/platform-dev -- Kind regards, Andrey Loskutov https://www.eclipse.org/user/aloskutov Спасение утопающих - дело рук самих утопающих ___ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
[platform-dev] Unsigned Content?
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-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
