Hi
"And this seems like short notice to me..." Yes, but it's a security
issue so we should try a little harder.
There seem to be two quick experiments to try.
a) just change Xtext's version bounds and see how many compilation
errors result. i.e. how many signature breakages are there?
b) if a) is tractable, just run the JUnit tests and see what breaks i.e.
how many functional breakages are there?
OCL which uses an unspecified Guava version, or rather the version
specified by Xtext. OCL is compatible with Xtext 2.10 to 2.18 and so the
corresponding Guava. This has required accommodating the removal of
deprecated methods. Not a problem since Guava is little used and
Iterables methods are easy to recode.
Regards
Ed Willink
On 16/05/2019 06:27, Christian Dietrich wrote:
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 <https://go.microsoft.com/fwlink/?LinkId=550986> für
Windows 10
*Von: *Ed Merks <mailto:[email protected]>
*Gesendet: *Donnerstag, 16. Mai 2019 07:19
*An: *[email protected]
<mailto:[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]
<mailto:[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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
