Greetings Committers.
Our communities have a reasonable expectation that open source projects will responsibly disclose, and -- to the extent possible -- fix, reported vulnerabilities. The
Eclipse Foundation Vulnerability Reporting Policy describes the principles by which we deal with vulnerability reports, including the principle that we disclose vulnerabilities after three months whether they are fixed or not. The policy has no specific requirement that vulnerabilities actually be patched; whether or not a vulnerability gets fixed is entirely a project team's decision.
Our practices for dealing with vulnerability reports are captured in the
handbook.
As I discussed in
my note in February, the Eclipse Foundation is a Common Vulnerabilities and Exposures (CVE) Numbering Authority, which grants us the ability (and responsibility) to report vulnerabilities to the world via the CVE Programme. The information that we provide is used (directly or indirectly) by adopters of our software and by various products and services (like
Eclipse Steady) to detect dependencies on components with known vulnerabilities.
We've evolved our practices for handling vulnerability reports a bit since I sent that last message.
The EMO has been strongly encouraging all project teams to create a SECURITY[.md] file in the root of each of their Git repositories that details how they want their community to report vulnerabilities and the project's policy regarding how they are handled (the EMO has started doing this as part of reviews). This is a best practice that is actively supported by
GitHub and others. At this point, we don't have a template ready; but, while
we work on creating a template (input and contributions welcome), the
Eclipse RDF4J project team has created a
good example that project teams can use as a basis for their own security policy document.
Note that like everything else we do, the security policy should be open, transparent, meritocratic, and vendor neutral. In this context, we tend to think of open as a level playing field for comitters (not necessarily open to the entire world), and transparency having a bit of lag between reporting and disclosure. If you're not sure, the EMO can help.
In the past, the EMO would only assign and report a vulnerability via the CVE Programme only when specifically requested by the project team. The EMO now takes some discretion in the matter and we will automatically disclose a vulnerability via the CVE Programme when we decide that one is required. We are, of course, able to provide better reports when the project team engages in the process to validate that the reported vulnerability is valid, and describe and categorize the nature of the vulnerability. Note that a vulnerability does not need to be fixed to be reported. Further, the EMO does not have the capability to actually fix vulnerabilities (at least not in general).
When we receive a report regarding a potential vulnerability, our first course of action is to check with the project's security policy, and -- to the extent possible -- follow that policy. In the absence of specific direction, we create a "committers-only" (confidential) issue in Bugzilla with the the project leads in copy and then send a note to the project's mailing list to let the project team know that we've created the issue (since the mailing list is public and has a public archive, we don't include any details). Note that we're working on sorting out how we move this from Bugzilla to GitLab (which supports a notion of confidential issues) instead.
As I said earlier, disclosure of vulnerabilities is expected from our community and is part of being a responsible open source project. The Eclipse Foundation's security team and the EMO are here to help.
Wayne
While I have your attention, we have a request from a team of researchers for your input into their study:
I, together with a team of researchers, am trying to help improving software documentation and maintainability of open-source projects by providing automatic support of source code comments based on code review discussions as a final goal. We believe that code review tools store important discussions, and possible decisions, which can be useful for the project documentation. Thus, we would like to learn identifying relevant information from code review discussions such that tooling can be developed to improve software documentation and maintainability of open-source projects.
Kind regards and thanks in advance,
Nicole Novielli, University of Bari,
Fernando Castor, Federal University of Pernambuco,
Christoph Treude, University of Adelaide,
Alexander Serebrenik, Eindhoven University of Technology,
Felipe Ebert, Eindhoven University of Technology
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation
