Ed, Thank you for your feedback. As people seem to prefer issues/discussions for such subjects, here they are: https://github.com/eclipse-platform/.github/discussions/143 (Coordinated dislosure for Eclipse Platform projects <https://github.com/eclipse-platform/.github/discussions/143>) https://github.com/eclipse-platform/.github/discussions/142 (A process for an emergency security releas <https://github.com/eclipse-platform/.github/discussions/142>e)
I've split the subject into two essential sub-problems, which are easier to understand and solve, I hope. Let's discuss there! Kind regards, Marta Rybczynska On Mon, Jul 24, 2023 at 10:05 AM Ed Merks via platform-dev < platform-dev@eclipse.org> wrote: > 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@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 >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
