Hello Ed and others, 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? Kind regards, Marta On Wed, Jul 19, 2023 at 9:31 AM Ed Merks via platform-dev < platform-dev@eclipse.org> wrote: > Marta, > > I notice this interesting blog has relevant background details: > > > https://newsroom.eclipse.org/eclipse-newsletter/2023/may/reporting-and-managing-security-issues-eclipse-foundation-projects > > With respect to timing, I see this in the policy: > > https://www.eclipse.org/security/policy/#timing > > 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: > > https://www.eclipse.org/security/policy/#distribution > > 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: > > https://ci.eclipse.org/simrel/ > > 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: > > > https://github.com/eclipse-platform/.github/discussions > https://github.com/eclipse-platform/.github/issues > > This related discussion is already underway: > > https://github.com/eclipse-platform/.github/discussions/129 > > Regards, > Ed > > 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? > > Thanks in advance, > Marta > > _______________________________________________ > 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 >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
