Coordinated dislosure for Eclipse Platform projects

[mrybczyn]

Imagine a situation where a common serious security issue has been found in multiple elements of the Platform simultaneously. This is quite common in the industry: a vulnerable code pattern, copy-pasting, or usage of the same library...

Attackers have time to exploit unfixed subprojects if one sub-project releases or commits a fix before others. It is a good practice to release such a fix simultaneously in all sub-projects.

Eclipse Platform already has important interactions between projects, so it should be quite easy to implement coordinated fixes and disclosures. Projects will need to know where such synchronization takes place. It might be the PMC, using a common ticket etc. Here, all sub-project decide on a common date and then release their advisories and CVE descriptions.

[merks]

The Eclipse top-level project has an aggregation build that builds all the subprojects projects, Equinox, PDE, JDT, and Platform.

https://ci.eclipse.org/releng/job/Builds/job/I-build-4.29/

It produces this unified update site:

https://download.eclipse.org/eclipse/updates/4.29-I-builds/

It also produces download pages such as this one:

https://download.eclipse.org/eclipse/downloads/drops4/S-4.29M1-202307051800/index.php

So how the sub-projects are built and made available is already coordinated today.

The 3rd party dependencies are also coordinated across the sub-projects via

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

You mention a "common ticket", but of course GitHub has issues, not tickets and these cannot be common across organizations. An issue could be created that references other related issues in other organizations. We could create such a common/umbrella issue here:

https://github.com/eclipse-platform/.github/issues

That could help group/coordinate related "sub-issues" across organizations.

[mrybczyn]

Thank you @merks for the description of the build process. Coordinated disclosure also has one more element: a coordinated discussion of when to release the fix. That means not only when to publish the release but also when to commit a fix in a public repository. Imagine a very serious issue. When one of the subprojects commits a fix, attackers might have a suggestion of a similar issue existing in other subprojects. Ideally, they all commit at the same time.

A common issue you mention could be a handy way to discuss if 1) it is a common issue 2) decide on the release to include a fix

[merks]

I suppose we will also need to (eventually?) imagine how to do such coordination across a much larger set of projects that comprise the Eclipse Simultaneous Release, not just across the Eclipse top-level project's subprojects:

https://projects.eclipse.org/releases/2023-06

Coordinating all this effectively, with some level of secrecy, will be even more challenging.

[mrybczyn]

Yes, definitely it is a challenge. Fortunately, releases like that are not very common, and when all projects involved know exactly what to do, it will become routine. It also happens only if the issue to address is judged serious. Low-severity security bugs can use the typical release process.

Typically, there is a small number of people who know the exact issue (1-2 persons in a project are usually enough, plus someone doing the release to ensure there are no regressions). Other subprojects might have designated people who know a security release is in progress but without details.