Community
Participate
Working Groups
Starting with 1.17.0, guava 20.0 is bundled in org.eclipse.m2e.maven.indexer. org.eclipse.m2e.maven.runtime currently bundles guava 25.1-android, at least since 1.16.0 (I did not check older versions). guava < 24.1.1 is vulnerable to CVE-2018-10237. guava < 30.0 is vulnerable to CVE-2020-8908. Any m2e components that depend on guava should update their dependency to 30.0+. Bundled guava should be updated to 30.0+.
I added 570581 as a blocker, but its more like a related issue. AFAIK, m2e bundles its guava and does not depend on Orbit to resolve it, so m2e should be able to update to Guava 30.0+ without it being available in Orbit.
Bug 570581 is not a blocker for m2e as the dependency comes from Maven Central. https://github.com/eclipse-m2e/m2e-core/blob/master/m2e-maven-runtime/org.eclipse.m2e.maven.indexer/pom.xml is where the fix should happen for m2e.
Here is a PR removing guava dependency from maven-indexer https://github.com/apache/maven-indexer/pull/75 . Hopefully they merge it and release so we can free from one useless dependency.
I have taken a look at the CVE's and think they rarely affect you in the context of m2e: CVE-2018-10237: allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data m2e is merely a server and do not de-serialize data revived from external sources CVE-2020-8908: allowing an attacker with access to the machine to potentially access data in a temporary directory if an attacker has access to your machine where you are running eclipse your really doomed. In an multi-user-env you should always configure your system with user-specific temporary locations not accessibly by other users As Alexander has shown with his PR at least the indexer makes no use at all of any affected code. So even though never versions with fixed security issues are a good thing, you shouldn't worry too much atm in the context of your IDE. If your using m2e outside the IDE and in a highly sensitive are of course deeper investigation and action might be necessary.
Thanks for comment 4, Christoph! I agree that the vulnerabilities are not serious, but our company policy requires us to fix CVEs before shipping software. Therefore even medium/low CVEs can block our ability to ship the Eclipse products that we maintain. Therefore I either need to remove features, fork features, upstream changes or some combination. Usually I remove non-critical features or fork temporarily, upstream as time permits, then de-fork or re-enable features when the fix is available from an Eclipse release.
Thanks a lot Tony!
I see maven indexer bundle using Guava 30, but what about other bundles : $ p2ql https://download.eclipse.org/technology/m2e/releases/1.17.2/ whatrequires ".*guava.*" IU: org.eclipse.m2e.core 1.17.2.20210211-1654 -> osgi.bundle; com.google.guava [27.1.0,28.0.0) IU: org.eclipse.m2e.editor 1.17.2.20210219-1922 -> osgi.bundle; com.google.guava 27.0.0 IU: org.eclipse.m2e.editor.xml 1.17.1.20210219-1922 -> osgi.bundle; com.google.guava [27.1.0,28.0.0) IU: org.eclipse.m2e.sourcelookup 1.17.1.20210115-1536 -> osgi.bundle; com.google.guava [27.1.0,28.0.0)
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
