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
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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
