The policy of EF reflects the reality in the industry. 90 days is the typical time security researchers agree to wait. However, this is not set in stone. It might happen that a researcher says they have a presentation accepted on a conference and they will present the vulnerability at that specific date. Or, a researcher who is following a different calendar, like 30 days. Or if there is an active exploitation of a vulnerability.
In such cases, if the project does not have a way to produce an emergency release in such cases, this could be bad for their users (and their reputation...). This is the risk I note in this case (EF policy is secondary here).
Also, this is also always a project's call to decide to do a security release or not. Usually, for a minor vulnerability, it is OK to wait. For a major one, it's another story.
It might be useful to start a discussion about cross-project security releases (we call it coordinated disclosure in the security world, btw), do I read it correctly that you prefer a GitHub issue instead of a mailing list post?
With respect to distribution of a resolution, I do not see the
use of, nor definition of, the term "security release" but rather
only the following, where it simply mentions using "normal
distribution channels" at a minimum:
In general, all changes are normally made available for
distribution within a day via integration builds, and, as you've
noted, releases are normally made available for distribution on a
quarterly basis.
Also highly relevant, is that the simultaneous release, the
mostly widely used distribution channel, is also normally
available quarterly. SimRel integration (staging) builds are
available daily with new content available as contributed by the
participating projects:
Asking for special out-of-band "security releases" is asking for
a lot from the Platform project. Too much in my personal
opinion, but everyone is entitled to an option. Moreover,
I assume this same policy, and expectation, applies uniformly for
all projects where that expectation is probably significantly less
realistic. It would seem better to me to try to work (as much as
possible) within the bounds of the existing processes and normal
distribution channels.
General cross-cutting discussions or issues can be hosted here:
On 18.07.2023 18:03, Marta Rybczynska
via platform-dev wrote:
Hello,
Eclipse
platform has been releasing every three month for some time.
I've been recently working on clarifying security processes
and I could not find a description how the Eclipse Platform
handles a security release.
Would a security fix need to wait for next 3-month
release? This could be in conflict with the 90 days
vulnerability release policy. Consider this scenario:
- A vulnerability is reported two weeks before the release
and the team needs some time to prepare a fix.
- The fix is ready one month after the release
- 90 days will come two weeks BEFORE the next release
Releasing a vulnerability information to the public without
a release fixing it is against best practices and it would be
beneficial to avoid it.
Do you consider running a separate bugfix release?
Could you please point me to documentation/discussions on
how you do handle or would handle such a situation?