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 list
platform-dev@eclipse.org
To unsubscribe from this list,
visithttps://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
