We at Xtext are affected by this. And we align to the release Train although our RC1 is ususally the final release. And we have very very limited capacity to work on anything. The Problem is that we cannot estimate the work (testing, Adaption) and having support for the new Version only would break older target platforms like Oxygen. Also we need to investigate how that interferes with Google Guice (used for injection, if update needed there too additional bureaucracy work with the foundation needed). Thus I preferr to do such things before M1 and not somewhen between M3 and a RC.
Thanks Christian Gesendet von Mail für Windows 10 Von: Ed Merks Gesendet: Donnerstag, 16. Mai 2019 07:19 An: [email protected] Betreff: Re: [cross-project-issues-dev] [Bug 547338] Update to guava 24.1.1+(fix CVE-2018-10237) This affects quite a few projects (Xtext comes to mind) and we know from past experience that shipping multiple versions of a library that's mostly resolved using package requirements (rather than bundle requirements) can result in problematic wiring resolutions. So generally we've tried to ensure that there is only one version of such a bundle in the release train repo. This seems to suggest that all projects contributing to the release train (and contributing Guava) all ought to use/contribute the same version of Guava and should all test that this works (or even compiles for that matter because Guava has a history of deleting things). Xtext's releases don't totally line up with those of the release train, so certainly a general move requiring all projects that contribute Guava to the release train all moving to a new version seems problematic; I think Xtext would need to plan a new release for this. And this seems like short notice to me... On 15.05.2019 21:38, Homer, Tony wrote: Thanks to Fred Bricon who suggested that I contact this list: >>Usually, guava versions need to be aligned across all Eclipse projects, so >>you might want to raise the issue in the cross-projects ML My team builds an Eclipse product which includes m2e. Our company policy requires us to scan for CVEs and we found several affecting m2e, including CVE-2018-10237, which m2e is exposed to via dependence on a vulnerable version of guava. m2e is currently using 21.0.0 which is the latest which is currently available in Orbit. The CVE is fixed starting with guava 24.1.1. The latest guava release is 27.1. In order to work around this issue, my team forked m2e locally and updated our fork to use guava 27.0.1 (as mentioned in Bug 547338). I’d like to add guava 27.0.1 or 27.1 (pending compatibility investigation) to orbit so that eclipse projects can switch to a guava that is not vulnerable to any published CVEs. I plan to open a change request with Orbit for this. What else is needed to move this forward in time for 2019-06? _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
