A process for an emergency security release

[mrybczyn]

Currently, the Eclipse Platform is releasing at 3-month cadence. Imagine scenarios like:

• An exploration of an unfixed vulnerability in the Platform or one of its dependencies reported in the wild
• A Security researcher who reports a security issue but can't/won't wait with the publication of the issue until the normal release date (for example, they have a presentation at an important conference)
• A serious issue found by a security researcher who is following a strict short disclosure date, like 30 days
• A serious issue in one of the Platform's dependencies is being fixed rapidly by other downstreams

In such cases, it might be highly recommended for the project to release an emergency security release faster than in the typical 90-day window. Such a need, when it arrives, might be urgent. I then recommend having a plan (if documented, even better) before.

Such a plan could include:

• who decides to perform such an emergency release? which criteria (eg. exploitation, CVSS of the issue...)
• which versions/branches are used? (a branch from the latest release, a branch from current versions at the time of the decision...)
• who knows that the release is in preparation?
• how to perform tests?

[laeubi]

Actually we have somewhat monthly release (M1/M2/m3) we just don't publish them... one way would be do simply switch to a monthly release by simplify the release process altogether (no freeze period, no "staging" or change of build schedules...).

[jonahgraham]

Many open source projects have gone in the monthly release direction in the past years (e.g. VSCode) it would make sense. However most of them continuously release multiple tracks (e.g. insiders and release). I can't see having monthly releases essentially off of main branch which is the source for (M1/M2/M3/etc). However having main and release branches being built continuously would be technically achievable, this feels like the same conversation we have had about resources many times before.

[jonahgraham]

Some projects, e.g. Eclipse CDT, already provide a way for emergency updates between the quarterly releases. The release branches are built and published as needed with only the critical changes and the p2 site of those updates are already populated in the Eclipse. Historically only 1 in every 3 or 4 releases even has such an update.

Eclipse Platform already has (e.g.) https://download.eclipse.org/eclipse/updates/4.28/ composite that updates can be published to, but similar to #142 (comment) it requires time to setup the builds so a respin can happen.

[jjohnstn]

Has any thought been given to how to notify users? While we already sometimes do emergency updates between quarterly releases, they are to fix major issues that a user can see a failure and then can find info on the update by searching on existing bug/issue reports. This likely won't be the case for a major security issue where nothing fails per se. Mailing lists/blogs can help but there will still be users out there that might not know to update until the next quarterly release and possibly not at all. Could something similar to the "Tip of the day" be used to warn users that a security update is available plus details?

[laeubi]

Eclipse already has update sites that can inform users about new things, one still need to have internet access. I already have suggested that a while back as log4shell was quite popular to have some kind of CVE Updatesite so the techniques are all there...

[merks]

The EPP packages all contain Oomph and every release I modify this URL:

https://github.com/eclipse-oomph/oomph/blob/fb8cff52c3bc44469028cab0a6b2ac88ba6d5c57/setups/org.eclipse.setup#L11

Normally that just opens this page (with some query string information) in a browser and remembers that so it doesn't do it again for that same URL:

https://www.eclipse.org/setups/donate/

So we have a mechanism whereby we can inform the user via a URL opened in a browser...

[merks]

I believe very few projects have the capacity to produce "emergency releases". Certainly for the Eclipse top-level project, producing a full blown release is a large investment of time across a significant number of involved parties.

For any regular problem, that problem is generally fixed in the master/main branch, and within a day, an integration build is produced containing that change. Most projects are capable of producing such changes on relatively short notice. Such a build produces an update site and that update site can be made generally available to allow users to update to a version with that fix. If the problem being fixed is a security problem, this mechanism can help users update very quickly to a version with the fix. For example, last night someone opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=582291 and the fix for that is already available now, as describe in the issue.

For SimRel, projects contribute such update sites for aggregation and we have this build the kicks in whenever anyone contributes an update:

https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/

That too produces an update site:

https://download.eclipse.org/staging/2023-09/

Via that existing mechanism, uses could update to a new version with a fix.

As such, we do already have processes and infrastructure in place for fixing problems, for producing new builds, and for making updates available to end-users. All that is just part of the regular development process as it exists today. Security fixes fit into this process...