Repository navigation
Meeting Minutes for Planning Council 2026-11-04 #100
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,57 @@ | ||
| # 2026-11-04 Meeting Notes | ||
|
|
||
| ## Agenda | ||
|
|
||
| - Planning council chair | ||
| - Status 2026-12 | ||
| - Priority board proposal: [A Sustainable Next Generation OSGi Resolver](https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/work_items/49) | ||
| - Invalid signatures of Eclipse executables on Windows | ||
|
|
||
|
|
||
| ## Minutes | ||
|
|
||
| ### Planning Council Chair | ||
| - Checked whether the current chair should continue serving, from both perspectives: | ||
| - Chair: willing to continue | ||
| - Members: in favor of the chair continuing | ||
| - No objections; Heiko continues as chair for now | ||
|
|
||
| ### Status 2026-12 | ||
| - Shape is considered good | ||
| - SPI replacement is in place, so ASM issues are mitigated | ||
| - CVEs | ||
| - SimRel/EPP SBOMs: https://sbom.eclipse.org/projects/e1ac111b-8567-403c-8df7-950588c102e9/collectionprojects | ||
| - Orbit SBOMs: https://sbom.eclipse.org/projects/a598db3e-3857-4ef2-a8ad-c75db18cdd35/collectionprojects | ||
| - Current Platform SDK has no CVEs, SimRel has few | ||
| - CVEs for older releases grow over time | ||
| - Goal for SimRel: keep dependency versions up to date, but do not require a release to be free of (critical) CVEs on release day | ||
|
|
||
| ### Priority Board Proposal: A Sustainable Next Generation OSGi Resolver | ||
| - https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg-dev-funded-efforts/ide-wg-dev-funded-program-planning-council-top-issues/-/work_items/49 | ||
| - General agreement that improvements on the resolver would be good: different issues with existing resolver in the community | ||
| - Raised questions / concerns | ||
| - Previous implementations (Felix, p2, Equinox) were hard to get right (NP-complete problem); it is unclear how much effort a new approach would need beyond the common 90% case | ||
| - Why not improve existing resolver / Felix? Is the new approach so fundamentally different? (Incremental) improvements would be less risky than a completely new implementation | ||
| - Funding would require a commitment to fix follow-up issues over an extended period | ||
| - Follow-up | ||
| - Ed will bring it to the PMC meeting, also to get Thomas Watson's opinion | ||
| - Discuss in the next meeting again with further input (Heiko will also invite Stefan Bischof) | ||
|
|
||
| ### Invalid Signatures of Eclipse Executables on Windows | ||
| - Signature of Oomph installer executable was invalid after an update on Windows | ||
| - Update process takes executable from p2 repository with a broken signature (see process below) | ||
| - Default signing / branding process: | ||
| - Signed executable comes from Equinox | ||
| - Branding with icon breaks signature | ||
| - Executable is then deployed to p2 repository (with broken signature) | ||
| - Building a product signs the executable again, so a product's executable has one broken signature from Equinox and one valid signature from product build | ||
| - Resulting requirement: | ||
| - When building products with branding and shipping the artifacts to p2, signing in the build must happen early enough to have the signed artifact in the p2 repository as well | ||
| - Currently not possible with Tycho out of the box | ||
|
There was a problem hiding this comment. I just want to note that this is not true (but also not very convenient) see documentation here: https://tycho.eclipseprojects.io/doc/latest/SignProducts.html It also contains a note that signing the executable itself is not really giving any security, it is more silencing maybe a warning.
Contributor
There was a problem hiding this comment. With regard to signing, it's true it can be made to work without modifying Tycho because @sratz fixed it like this in Oomph and BIRT: It's quite convoluted mind you, but no one will argue with success. 😁 On Windows, the executable in the repository that is "corrupted" by the branding icon (and is only fixed by signing it after branding has stuffed in an icon) can and does lead to Windows refusing to launch the executable, so it's much worse than a warning. That's what @jonahgraham noticed last week and mentioned at the planning council as well. But now the secondary problem is completely fixed because the latest signing service can even remove the corrupted signature so that the executable only has a single valid signature: 🥳 There was a problem hiding this comment.
Yes and it uses ant or bash ... I just wanted to note that there is a plain maven solution documented at Tycho so saying "Currently not possible with Tycho out of the box" seems questionable to me (and contradicting given @sratz fixed it now for oomph+birt) - depending on how one defines OOTB of course, given that there is no standard solution to sign any-ways (Eclipse Signing Service is only available to Eclipse of course).
Contributor
There was a problem hiding this comment. I thought I already agreed with you. 🤓 When someone contributes a working solution, I don’t “look the gift horse in the mouth” as the saying goes. Maybe there’s a nicer way, probably given your comment. The build of the installer is not so pretty to begin with because we generate several variations of the product on the fly. Maybe there’s a nicer way for that too. I’m not as skilled as you. Pull requests are welcome as we like to say in our trade. 🤗 We all think Tycho is awesome, and as you say, there are no standard signing services that could just be built in. If there were and there were sufficient funding, we could probably provide something more streamlined. I’m just happy that what comes out at the end is good and happy it works purely by making changes in my build steps, i.e., it works out of the box. |
||
| - Sebastian will propose a PR embedding signing at the right point in the build process of Oomph to have artifact already signed for p2 deployment | ||
| - _Editorial remark_: Sebastian already improved Oomph build (https://github.com/eclipse-oomph/oomph/pull/211) and proposed an enhancement to CBI (https://github.com/eclipse-cbi/org.eclipse.cbi/pull/990) | ||
|
|
||
|
|
||
| ## Next Meeting | ||
|
|
||
| Next meeting will be on December 2nd, 2026. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is anything unclear from the proposal I would be happy to answer open questions, maybe the gitlab issue is a better place than the meeting minutes, so just let me know if additional information is desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposal was well written and well received. Mostly we wanted opinions from other "experts" because none of us can claim to be an expert...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it seems there are some open question I just wanted to offer to clarify / follow up on them if wanted (but as mentioned maybe better in the gitlab ticket) - before or after getting in touch with other stakeholders - so just let me know then.