Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [Bug 547338] Update to guava 24.1.1+(fix CVE-2018-10237)

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.




Gesendet von Mail für Windows 10


Von: Ed Merks
Gesendet: Donnerstag, 16. Mai 2019 07:19
An: cross-project-issues-dev@xxxxxxxxxxx
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit


Back to the top