Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Contributing patches
Contributing patches [message #1863676] Tue, 20 February 2024 23:27 Go to next message
Eclipse UserFriend
Hi.

Xtext, Xtend (1 and 2) as well as Xpand still have a dependency on Log4j 1, which, as I'm sure you know, reached its end-of-life in 2015 and suffers from numerous vulnerabilities. Vulnerabilities have also been found in Log4j 2, perhaps most famously CVE-2021-44228 (Log4Shell), but later versions have addressed them and, unlike Log4j 1, has active development. This presents a problem for projects that depend on Xtext or Xtend and need to be run in organizations that have strict security requirements.

Over the past few months I've been patching Xtext, Xtend (1 and 2) and Xpand to replace Log4j 1 with Log4j 2, as part of patching it in multiple other Eclipse projects like ECF, GMF, MWE (1 and 2), Nebula, OCL, Papyrus, a couple of Apache bundles and Eclipse itself (platform and (e4)rcp), for a project with my employer, and I would like to contribute these patches to the Xtext/Xtend project (as well as to the rest).

I have not patched all of Xtext, but I've patched 32 bundles (including org.eclipse.xtext.logging), and the patches are on Xtext 2.31, which is what we needed for our project. Nevertheless, I think it could be a good contribution to the project, and perhaps someone else can rebase them on the latest version and complete the remaining bundles, which should be more manageable.

Is this something that the Xtext maintainers would be interested in?

Thanks

[Updated on: Tue, 20 February 2024 23:29] by Moderator

Report message to a moderator

Re: Contributing patches [message #1863681 is a reply to message #1863676] Wed, 21 February 2024 04:43 Go to previous messageGo to next message
Eclipse UserFriend
You may open as GitHub issue to discuss
But the Cappa of the project is very limited

Very naive question:
What is wrong with the use of reload4j to patch the security flaws ?
Re: Contributing patches [message #1863683 is a reply to message #1863681] Wed, 21 February 2024 08:34 Go to previous messageGo to next message
Tamas Miklossy is currently offline Tamas MiklossyFriend
Messages: 162
Registered: February 2016
Senior Member
See also https://github.com/eclipse/xtext/issues/2761
Re: Contributing patches [message #1863700 is a reply to message #1863683] Wed, 21 February 2024 18:43 Go to previous messageGo to next message
Eclipse UserFriend
Hi Christian and Tamas,

Thanks for the info. I will open an issue on GitHub.

I wasn't aware of reload4j, and I have just taken a look at it. I need to take a deeper look, but I'm not sure yet if it will be enough, at least for our purpose. The main reason is, sadly, bureaucracy. Basically we are building a Papyrus-based product, which of course includes Xtext and Xtend, and our customer for that product is a very large american company with very stringent security requirements for all the software their developers use. Their security department flagged our tool because it bundled log4j 1.2.x (I think it was 1.2.15) and essentially told us to remove *all* traces of it. This was all because of the Log4Shell bug. We tried explaining that that specific bug doesn't really affect the 1.2.15 version, that only affects web-apps, not desktop apps and that it requires running an executable that is not run by out tool at all, and that even the CISA-provided script to check for the vulnerability clears the product, but alas, while our engineering contacts in that company understand it, their security department doesn't and refuses to accept it unless we remove *all* traces of anything that has "log4j" and "1.x" in it. So for example, they would even refuse the log4j "bridge" provided by Apache (https://logging.apache.org/log4j/2.x/manual/migration.html) because the jar file is called log4j-1.2-api.jar! It is plainly blind and deaf bureaucracy and unjustified red-tape meant to give the impression of security instead of really looking into the issue, but unfortunately our only option is to comply. I have done so by creating these patches, but I, my company, and our contacts in the engineering team of that company, think that it would be a good idea to contribute these patches to the open-source community as others might benefit from it.
Re: Contributing patches [message #1863717 is a reply to message #1863700] Thu, 22 February 2024 19:26 Go to previous message
Eclipse UserFriend
I've opened GitHub issue #2940.
Previous Topic:How to change the QualifiedNameProvider from another language
Next Topic:Upgrading Xtext/Xtend Versions
Goto Forum:
  


Current Time: Sat Feb 08 01:32:11 GMT 2025

Powered by FUDForum. Page generated in 0.04076 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top