| Re: [platform-dev] Process for a security/bugfix release for the Eclipse Platform |
_______________________________________________Marta,
Note that all the opinions I express are my own. I do not speak for the Platform.
My opinions reflect the reality of the great many projects supported by a handful of committers (or even a single committer) doing everything on a for-free basis. While the focus here right now may be on the Platform's set of projects, that focus will (must?) eventually broaden to include all of SimRel (and effectively all Eclipse Projects and all their dependencies) because security problems can come from anywhere and from any Project. I would hope that most projects could produce a new build on short noticed, but I know that even that's unfortunately (and shockingly) not the case. Certainly the Platform is more than capable of producing a build on a moment's notice, and such a build (p2 update site) could be termed an "emergency release", but I think you probably are using that term to mean something much more.
In any case, please don't get me wrong. I fully share the Foundation's concerns about loss of reputation and the Foundation's goal of being an industry leader. The reality though is that the Foundation has a budget while Projects don't.
I believe that probably I speak for most of the Platform committers when I say that I prefer this discussion on a GitHub issue or GitHub discussion. Likely no one wants a long disconnected set of email threads on such a topic, and after the fact, someone will likely want a single location with a cohesive thread of discussion rather than a disjointed mailing list archive. I wonder if the focus on the Platform is a bit of the case of looking for a lost set of keys under the streetlight because the lighting is best for finding lost things there. It's just as likely that the keys will be lost in some dark corner, or deep in the grass. But I suppose one has to start looking somewhere. This issue is also very likely of interest to the IDE Working Group, which also has a budget...
Regards,
Ed
On 24.07.2023 09:25, Marta Rybczynska wrote:
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@xxxxxxxxxxx> wrote:
_______________________________________________Marta,
I notice this interesting blog has relevant background details:
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/issuesThis 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 releaseReleasing 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 list platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev