Community
Participate
Working Groups
One more thing for our plate: I need to draft a security policy and procedures document, and I'd like your help. The motivation here is that we have discovered a handful of security issues across several projects. As our projects continue to diversify and find adoption in diverse areas, we expect that additional security issues will be uncovered. We at the Foundation would rather like to be prepared to deal with these issues. Of course, we need to balance this with the ever-increasing demands on project resources, so I do intend to be sensitive to that. As for a policy, the expect that our eclipse.org-wide policy will be something along the lines of "We care about security" as it is impossible for eclipse.org to implement specific policies with regard to timeliness of fixes, rebuilds, and that sort of thing. Ultimately, the response to a disclosed security issue is wholly dependent on the individual projects. In that regard, I'm thinking that we'd all be better served by a well-documented set of best practices for dealing with security issues, coupled with support processes and infrastructure where possible/sensible. To keep the scope of this bug as focussed as possible, I'd like to restrict the conversation here to that of actual policy, and I'll open subtasks/blocker bugs to cover discussion of specific procedures/best practices.
One thing that should be in place, is that projects should monitor any of the third party depenencies they currently use for Security fix related releases. If a security fix related release occurs, then that project should update as soon as possible to that fixed version of the dependency.
one thing that has always bothered me about osgi is its nature to be very open in terms of versioning and what it runs with, so these sorts of security issues forcing minimal versions to be put into metadata seems very difficult to enforce, or even force really. Maybe there is an easy way and if there is then that ought to be front and center in terms of any policy. I mean specifics on 'Set X in the metadata of Y' dave alludes to this in his followup on that post about 'fixing' a version so I was wondering if there was an osgi policy or spec for dealing with this sort of situation and if there is maybe you could link to it in the bug?
We should consider mirror tampering. I get an email every few months warning me that the md5sum for a file downloaded from a mirror doesn't match.
(In reply to comment #2) > one thing that has always bothered me about osgi is its nature to be very open > in terms of versioning and what it runs with, so these sorts of security issues > forcing minimal versions to be put into metadata seems very difficult to > enforce, or even force really. Maybe there is an easy way and if there is then > that ought to be front and center in terms of any policy. I mean specifics on > 'Set X in the metadata of Y' > > dave alludes to this in his followup on that post about 'fixing' a version so I > was wondering if there was an osgi policy or spec for dealing with this sort of > situation and if there is maybe you could link to it in the bug? I don't think there is any OSGi policy for security issues in particular. The recommended versioning guidelines from OSGi recommend incrementing the micro version for bug fixes that do not affect API. I think most security bug fixes do not change API, but I can imagine cases where a fix could change API. In most cases OSGi recommends clients tolerate changes in the minor version. So you would import/require a range like [1.0,1.1). Just to make sure I understand you concern. A client X has a dependency on Y version [1.0,1.1). It turns out Y version 1.0 has a security bug. A fix is put out to Y in version 1.0.1. Now X can use either version of Y 1.0.0 or 1.0.1 according to its range. In my opinion we should not recommend all clients of Y update their version range to exclude Y version 1.0. Instead we should focus on how we can deliver an update to Y version 1.0 to version 1.0.1 in the installations that include Y version 1.0.
Regarding Comment #3, I would look at Bug 334323 for a more likely explanation of reports of md5 checksum mismatch.
(In reply to comment #5) > Regarding Comment #3, I would look at Bug 334323 for a more likely explanation > of reports of md5 checksum mismatch. Right. The part that I left out is that every time I get one of these emails about potential mirror tampering, it turns out to be a misunderstanding.
> Right. The part that I left out is that every time I get one of these emails > about potential mirror tampering, it turns out to be a misunderstanding. I wouldn't call it a misunderstanding when eclipse.org download server reports a checksum that doesn't match the original files held on eclipse.org... Can't do anything about trying to detect mirror tampering before we fix that.
(In reply to comment #7) > > Right. The part that I left out is that every time I get one of these emails > > about potential mirror tampering, it turns out to be a misunderstanding. > > I wouldn't call it a misunderstanding when eclipse.org download server reports > a checksum that doesn't match the original files held on eclipse.org... Can't > do anything about trying to detect mirror tampering before we fix that. I agree in principle. However, I was trying to be kind with my use of the word "misunderstanding". Let me try to be more clear: without exception, every email to EMO reporting that the checksum for a particular file is wrong, is a result of the reporter doing something incorrectly. Check that... I recall that there was one case where the MD5s weren't updated properly on a project page, but that's not an issue with the mirrors...
> Let me try to be more clear: without exception, every email to EMO reporting > that the checksum for a particular file is wrong, is a result of the reporter > doing something incorrectly. Maybe we are talking about different things. I have reported a number of checksum verification failures (to webmaster) after confirming that it wasn't an issue with a particular mirror. There are cases where the original file on eclipse.org servers doesn't match checksums published by the checksums service (note that I am not referring to checksums that projects publish on their own). Take a look at Bug 334323 for an in-depth discussion on this.
I've posted my initial crack at this policy on the wiki: http://wiki.eclipse.org/Drafts/Security_Policy There's still lots to do...
This bug seems so close to resolution it feels like a waste to let it linger. Maybe we can finalize it at our next Architecture Council meeting? It seems there are just a couple of actions to make this real: - Presumably get board approval - Create security@eclipse.org mailing list for reporting - Create a Disclosures page that lists fixed/disclosed bugs, and provides bugzilla queries to undisclosed security bugs - Remove word "DRAFT" from security policy page
One thing that I found missing in the Security Policy draft as of today was some channel by which Member Companies can subscribe to receiving notifications about security vulnerabilities. I'd expect that a Member Company may be interested in receiving such notifications even if that member company does not have any committers. Obviously the "public disclosure" should support some form of push notification (RSS, Mailing List, ...) but I'd assume that Member Companies should be allowed the privilege of being notified before public disclosure ?
Another addition that should be considered is the Long Term Support initiative and the role of LTS IWG members. They are *very* interested in security related information.
(In reply to comment #13) > Another addition that should be considered is the Long Term Support initiative > and the role of LTS IWG members. They are *very* interested in security related > information. Good point. I've added Andrew Ross to the CC list.
(In reply to comment #12) > One thing that I found missing in the Security Policy draft as of today was > some channel by which Member Companies can subscribe to receiving notifications > about security vulnerabilities. > > I'd expect that a Member Company may be interested in receiving such > notifications even if that member company does not have any committers. > > Obviously the "public disclosure" should support some form of push notification > (RSS, Mailing List, ...) but I'd assume that Member Companies should be allowed > the privilege of being notified before public disclosure ? How about this? https://bugs.eclipse.org/bugs/buglist.cgi?columnlist=bug_severity%2Cpriority%2Creporter%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&keywords=security&keywords_type=allwords&query_format=advanced&title=Bug%20List&ctype=atom Note that the list of bugs will contain "committers-only" bugs if you're logged into Bugzilla with committer credentials. They will be omitted otherwise.
(In reply to comment #15) > How about this? By way of clarification, I am suggesting that I will include a "Feed" link on the security page which provides this URL.
Another important issue is that the /security page isn't well connected into the website. I'm thinking that a link from the Bugzilla home page would be a good start. A link from the "Development Resources" wiki page is a no-brainer. Where else?
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.
While there is room for small improvements I think the process and documentation rolled out at https://www.eclipse.org/security/ satisfies the requirements of this bug. Closing.
