Community
Participate
Working Groups
The security policy must address distribution issues. "All Vulnerabilities affecting projects that participate in the Simultaneous Release must be reported to the Planning Council prior to full disclosure to the community at large. Disclosure of a Vulnerability must be coordinated with the distribution of the updated software from the Project's own distribution channels, the Simultaneous Release repository, and EPP packages." I need to add a little something about the Planning Council deciding whether or not to respin. I figure the actual communication will happen via direct email from the project leadership to their PMC's Planning Council Representative. Thoughts?
I know you're thinking of this, Wayne, but the Linux distributions that ship Eclipse-based IDEs/products should also be kept in the loop.
(In reply to comment #1) > I know you're thinking of this, Wayne, but the Linux distributions that ship > Eclipse-based IDEs/products should also be kept in the loop. Indeed. What is a good mechanism? I'm not too concerned about Red Hat (there's enough deeply involved Red Hat people at Eclipse that I'll bet we'd have to try hard to keep them out of the loop). We do not, however, keep track of adopters in any formal way. Communication between Eclipse projects is a big part of why I want a representative from each PMC on the Security Team. I'm not exactly sure how to grow this outside of the organization, though. I envision a project making contact with known adopters to advise them of the issue and invite them to participate on a bug as a solution is being adopted. This leaves the onus on each project (and those people already copied on a bug) to have some sense for who the adopters are and reach out to them. Thoughts?
My limited experience with other open source projects is that there is a closed mailing list with (trusted) distribution packagers who get notified and coordinate preparation of packages so that they can release advisories on the same day. These packagers are given access to patches before their general availability.
Any thoughts on how we establish trust in a consistent manner? Friends of friends?
(In reply to comment #4) > Any thoughts on how we establish trust in a consistent manner? Friends of > friends? I think that's how it's been done for other projects. I forgot to mention that many (most?) of the Linux distributions shipping Eclipse IDEs build upon the Linux Tools project's eclipse-build work [1] so that project could roll new tarballs with security patches and disseminate them fairly easily. [1] http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build
Keep in mind there are two general mechanisms for delivering a security fix: 1) A patch. This is something installed on top of an existing installed product. Anyone can create a patch and make it available. A patch could be hosted in a separate repository, or in the same repo as your product updates. There is currently no mechanism in p2 to find and install critical patches automatically, but this is something that could be done in the future. Currently the user has to take the manual step to locate the patch and install it. 2) A new version of the product. Create a new version of the product that is an "update" of the old version. The new version would have to be produced by the project that produced the original version. p2 can be configured to find and install updates automatically (although this is turned off by default). Creating a new version is a relatively heavyweight task. For a fix that appears in the base platform, for example, all EPP packages would need to be regenerated. You seem to be assuming approach 2) from your text above. This is a reasonable approach for addressing a severe problem in a release that has occurred quite recently. The build mechanism should still be in place to perform another release without too much overhead (probably a person-week of effort in total). However, what about fixing a vulnerability in a release from several years ago? I doubt we could respin an EPP build from a few years ago without lots of work. Also for a relatively minor security fix, creating a new product version would be too much work for the reward. I think a general policy should just state that the affected project(s) produce and distribute a fix in a timely manner, without specifying the form the fix takes (patch or new product version). With a bit of work in p2, I think patches could become the principle mechanism for delivering security fixes, so I wouldn't want to bake in a policy that says we deliver a new product version every time.
(In reply to comment #6) > I think a general policy should just state that the affected project(s) produce > and distribute a fix in a timely manner, without specifying the form the fix > takes (patch or new product version). To be more clear, I suggest we require projects produce a fix in a form that can be directly installed by an end user into the affected product. One could otherwise interpret "make a fix available" as attaching a patch in bugzilla or committing a fix to CVS.
(In reply to comment #7) > To be more clear, I suggest we require projects produce a fix in a form that can > be directly installed by an end user into the affected product. One could > otherwise interpret "make a fix available" as attaching a patch in bugzilla or > committing a fix to CVS. I prefer to defer to the judgement of the parties involved to do what's best for their community. Not all projects produce "products" that can provide fixes that are installable by end-users. Equinox and EclipseLink come to mind.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Still a "bug". Hence will remove "stale-bug" from the whiteboard. See related bug 509389.
So, I'm stuck on this point. (In reply to Wayne Beaton from comment #8) > I prefer to defer to the judgement of the parties involved to do what's best > for their community. I'm not sure what we can do as an organization other than count on the parties involved to know what need to be done to best serve their communities. Project teams (and the PMC in some cases) are in the best position to know how to best distribute patches and updates. With regard to communication, perhaps we can make it a policy to report all vulnerabilities to the Eclipse Architecture Council and Eclipse Planning Council. These bodies have the broadest view of our project space and the communities beyond. Further, both of these bodies have regular conference calls that can be used to discuss issues before they are disclosed. I assume that anybody who cares about vulnerabilities, bugs, and other issues in a project is probably engaged with that project. e.g. I would expect individuals who package the Eclipse IDE for distribution on Linux to be engaged with the Eclipse Package Project and maybe projects like Eclipse JDT and Eclipse CDT via their dev lists. Is the requirement to disclose vulnerabilities via project channels in a timely manner enough?
I will just dump a few thoughts on my own in the hope this helps the discussion and doesn't make things more complicated. ;-) What I've read so far is all very focused in Eclipse as an IDE. However, looking at Eclipse IoT for example, most projects are completely different. They don't even join the release train. However those projects also sometime have vulnerabilities, which need to be addressed accordingly. I know from a first hand experience that Wayne's assumption is not 100% correct: > I assume that anybody who cares about vulnerabilities, bugs, and other issues in a project is probably engaged with that project. Sometimes you get contacted by security researchers, which "just" want to write a paper or get some sort of credibility be finding an issue in your project, yet they don't really care about that project. So they don't really care about Eclipse, Eclipse's Security Policy or the community. Additionally not every project seems to have an interest in fixing security issues. As strange as that might sound. In my opinion there has to be some sort of triage outside of the project itself. If it is a vulnerability a CVE number would help for referencing. There has to be a publicly accessible list of disclosed CVEs (from Eclipse). When and how a project provides an update, should be up to the project. But the fact that the project has an issue should be made available outside of the project. Of course not bypassing the project! But having proper CVEs, downstream distributions can properly reference. Other Eclipse projects can properly reference issues in dependencies. And, if the project in question does not provide an update, fix or workaround, there is a straight forward way for the community or users of that dependency to ask for a fix. I do think that raising awareness to vulnerabilities is the first step to improving the distribution situation.
(In reply to Jens Reimann from comment #13) > I know from a first hand experience that Wayne's assumption is not 100% > correct: > > > I assume that anybody who cares about vulnerabilities, bugs, and other issues in a project is probably engaged with that project. > > Sometimes you get contacted by security researchers, which "just" want to > write a paper or get some sort of credibility be finding an issue in your > project, yet they don't really care about that project. So they don't really > care about Eclipse, Eclipse's Security Policy or the community. I actually meant consumers. Consumers that care about a project should be monitoring communication channels associated with that project. If they're not, then I'm not all that sure how we connect with them. We do maintain a disclosed vulnerabilities page. I do intend to become a CNA, but that doesn't necessarily solve the dissemination problem. > Additionally not every project seems to have an interest in fixing security > issues. As strange as that might sound. I'm not sure how we address this. I don't necessarily believe that it is the EF's job to force project teams to deal with issues of any particular sort. For security issues, if they're reported and not dealt with, we'll disclose them after they've sat. If the project team and/or consumers don't care, then I guess that we're done. Again, consumers who care should be paying attention. If security issues are not being addressed, they're the best ones to either apply pressure and/or commit resources to addressing the issues. > In my opinion there has to be some sort of triage outside of the project > itself. If it is a vulnerability a CVE number would help for referencing. > There has to be a publicly accessible list of disclosed CVEs (from Eclipse). Working on it (I'll open a bug). Once we've become a CNA, we'll include CVE numbers in the disclosure list. > When and how a project provides an update, should be up to the project. But > the fact that the project has an issue should be made available outside of > the project. Of course not bypassing the project! I agree in principle. But "when" cannot be "never". IMHO, three months is plenty of time.
(In reply to Wayne Beaton from comment #14) > I'm not sure how we address this. I don't necessarily believe that it is the > EF's job to force project teams to deal with issues of any particular sort. > For security issues, if they're reported and not dealt with, we'll disclose > them after they've sat. If the project team and/or consumers don't care, > then I guess that we're done. Agreed. Maybe we should add a marker in the list of disclosed issues which ones are fixed and which ones are unresolved. That state could come from bugzilla and would raise the awareness. > > When and how a project provides an update, should be up to the project. But > > the fact that the project has an issue should be made available outside of > > the project. Of course not bypassing the project! > > I agree in principle. But "when" cannot be "never". IMHO, three months is > plenty of time. Absolutely!
Like I said in Bug 500333: > I think that this follows pretty naturally from our existing policy and > process. Do we need to document this formally? (I'm thinking no) The security team is the circle of trust. It includes members from the committer community who are directly involved in addressing vulnerability issues and representatives from the PMCs. I have engaged the CVE to become a CVE Numbering Authority. When that application process is complete, we'll add CVE number assignment to the process (BUg 514571). I hesitate to document specific solutions for a variety of technologies. The general solution is basically "engage with the teams that are impacted by the issues and resolve them in a manner that makes the most sense for their community and consumers". IMHO, the intent of this bug has been addressed and I'm marking it as FIXED.
