Upgrade Papyrus version

[J17359]

Issue and tracking information

Developer's time Estimated effort to fix (hours):

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

Ideally, upgrade to the latest version of Papyrus, but I'll leave that up to you to evaluate. I'd say at least 6.x. The version CX currently delivers is 4.8.0 (2020-06). There are two newer major releases 5.x and 6.x available on their home-page.

[eposse]

A quick status report.

I have been finally able to make a target platform based on the Papyrus 6.5 (2023-06) SDK, and after updating a lot of dependencies on manifest files, I am able to compile all (except for Papyrus Compare) within Eclipse. I have not yet tested it.

Next steps (not necessarily in order, as dependency management may require updates):

1. Try to build it with Maven.
2. Adjust the RCP product as needed by the new dependencies.
3. Test.
4. Include and adjust Papyrus Compare.

[eposse]

An update.

I got it building with Maven, including the Papyrus patch, but without Papyrus Compare, and updated the RCP product, although I might need to streamline the list of dependencies in the RCP product, as it seems to be getting too large, but that's a secondary concern at the moment.

I'm going to be testing now.

[eposse]

Some important info:

After building, I discovered that the RCP still contains two versions of log4j 1.2, in addition to log4j 2:

org.apache.log4j_1.2.15.v201012070815.jar
org.apache.log4j_1.2.24.v20221221-2012.jar
org.apache.logging.log4j_2.17.1.v20220106-2156.jar

Version 1.2.15 could possibly be explained by one of our existing plugins still having that dependency, but I didn't understand the presence of the 1.2.24 version, until I looked at a plain Papyrus install, and it turns out that plain Papyrus is the one that includes it, in addition to 2.17.1.

So there doesn't seem to be a clean way to simply get rid of log4j 1.x by upgrading (or otherwise)

I will investigate to see if perhaps I can find which plugins are dependent on 1.2.x, and hopefully I can patch them. The problem is that it may be a third party dependency, like EMF Compare, or worse, Xtext. This is very, very difficult because these, as well as Papyrus itself, have a very large code base.

[eposse]

And more info about this.

I have tried to install several variants of Eclipse to see which ones come with versions of log4j, and in particular I tried the following ones which are all relevant as they all include features that are included in Papyrus CX. They are all based on the latest release, which is 2023-06:

Eclipse RCP................................... Includes log4j ........ log4j versions
-----------------------------------------------------------------------------------
Eclipse Platform (minimal Eclipse install).... No
Eclipse for C/C++ Developers.................. No
Eclipse for Java Developers................... No
Eclipse for Java and DSL Developers........... Yes .................... 1.2.24
Eclipse Modeling Tools........................ Yes .................... 1.2.24
Papyrus....................................... Yes .................... 1.2.24, 2.17.1

So clearly version 1.2.24 comes from components in both the DSL package and/or the modelling package and Papyrus includes a great deal of both of these. These share a lot in common. My guess is that Xtext is the main culprit. I have been following details of Xtext development and they have been in trouble for at least two years with a lack of developers, so upgrades there are very unlikely. This is a big problem, because Xtext is huge, with an extremely complex code base.

I'll try to confirm which features and plugins exactly require 1.2.24.

EDIT: another relevant link, Message #1851012 from the Eclipse forums. Further information supporting the claim that the org.apache.log4j_1.2.x bundles are not the ones with the vulnerability, in spite of the version number.

[eposse]

My fears proved to be correct. Xtext (the latest version) depends on org.apache.log4j 1.2.24. And it's not just a few plugins that could be easily patched. It is all over the place: all 4 features including the "top-level" features and 71 plugins!!!

Removing this dependency will be very, very, very difficult, and you should take into account that we are not familiar with its code-base.

I will try to see how many of those plugins are actually included in Papyrus, in case its a smaller number that I can patch.

But either way, this is going to take a lot longer that we may have thought.

Xtext has a closed issue on migrating to log4j2 but the discussion there is that they do not have the capacity to do so. There are some suggestions on what to do in that discussion, but I don't know if they would completely remove the 1.2.x versions. I'm reading on them. The discussion is found in this link. EDIT: Note that the issue was closed, so basically, there is no movement from Xtext on this.

[eposse]

An update:

I am working on trying to patch Xtext to use the latest version of log4j 2.

Plain Papyrus has 18 Xtext plugins. Unfortunately, there is no feature in plain Papyrus that includes these plugins explicitly. They are brought in during the build because they are listed as dependencies in some of Papyrus plugins MANIFEST.MF files. Now, this is a problem (that there is no explicit Papyrus feature with them) because it means there is no feature to patch. In an Eclipse product, if you want to patch a plugin, you can only do it by patching a feature that contains the plugin. Now, in Papyrus CX, we actually do include four Xtext features, so we can patch those. The problem is that it requires patching 36 plugins rather than 18. So it's double the work.

The good news is that I have been able to patch one Xtext plugin. 35 to go. Having done one, the others should, in theory, be easier, and a bit faster, but it's still quite a lot. And then after that, I will likely need to patch several other features, likely OCL, Xtend, Xpand, EMF Compare and maybe others. So it will take time.

[emammoser]

Thank you for your persistence, we appreciate it. We are still trying to get direct answers from our security team on what is/isn't allowed. We realize that Log4j 1 has had numerous updates and CVE's discovered and fixed, however, it is my current understanding that anything log4j 1 is not going to be allowed. As soon as I get an answer different from that I will let you know, but I do think we should continue working on replacing log4j1 entirely, as you have been.

Is there any chance that once you do manage to patch these plugins, you could push these patches to the official branches for Xtext? If we can help the open source community version patching them locally before building and packaging, that would be our preference.

[eposse]

I was thinking exactly that, to push my updates to the official Xtext repo. However, the full Xtext includes something like ~70 plugins, so patching all would still be a bit of a tall order. Furthermore, I'm doing the updates based on the latest release, (used by Papyrus) which is 2.31.0, but they are working on 2.32, so it might be a bit of a catch up game. Of course, I could try to update all their plugins if you wish me to do so, but that would take time away from dealing with CX issues directly, and I will still need to patch other things like OCL, Xtend, etc. It's up to you to set the priorities. But I might still do a pull request in their GitHub repo, so that at least others can continue.

[emammoser]

Yes, I agree with you completely. We can push up the changes in an attempt to contribute but let's not put any extraneous effort into getting our changes accepted by their product.

[eposse]

An update:

I have patched almost the entire Xtext Runtime feature, 9 out of 10 plugins. I'm working on the 10th, which is the trickiest, as it deals directly with Log4j' extension mechanism, which changed a lot from Log4j 1 to Log4j 2. After that one, I think the remaining 26 Xtext plugins (in 3 features) will be a lot easier.

[emammoser]

Glad to hear you are making good progress. Thank you for the update.

[eposse]

A status update:

• I've migrated a total of 21 Xtext plugins from Log4j 1 to Log4j 2; this includes all the plugins in the main Xtext features included, but not the Xtext features included in the Xtend features
• I've migrated 3 Xtext plugins from Apache Commons Logging (JCL) to SLF4J
• I've migrated 5 CX plugins from Apache Commons Logging (JCL) to SLF4J

The last two need a bit of an explanation. Many plugins, both ours and our dependencies use "Apache Commons Logging" (previously known as Jakarta Commons Logging or JCL), which is provided by the org.apache.commons.logging plugin, provided by the Orbit repository, and unfortunately, this plugin depends on Log4j 1.2.x. SLF4J is a Java facade for several logging services, and it is easy to migrate from JCL to it, and it doesn't depend on Log4j 1.2.x. In fact, we could also migrate all Log4j to SLF4J instead, but at least for now, I'm trying to do whatever causes the least possible disruption.

[eposse]

Another update.

I've run into a big hurdle that has complicated the process of patching. Normally the dependency on log4j is declared in plugins, and those are the once I'm patching. But features can also declare hard requirements, and there are several features, including the core Xtext feature that declares log4j 1.2 as a hard requirement. These hard requirements are installed when the feature is installed. This is a problem, because the typical way to patch Eclipse products is to define a "Feature Patch" that specifies which feature is being patched and the plugins with the updates. But they way this works is that when Eclipse installs the feature patch, it first checks that the original feature is installed, and if not, it installs it, and then installs the patch, replacing the old versions of the patched plugins with the new ones included in the feature patch. But since it installs the original feature first, it also installs its required features and plugins, which in our case is the old Log4j 1. So this means that we cannot use the usual feature patching mechanism. Instead what I am trying is to copy the original feature entirely, removing the hard requirement to Log4j 1, and include this updated feature instead. It has been very difficult to build the product this way, but it looks like I have been able to build one with the new versions of the features.

Nevertheless, there are still many other features and plugins that have the log4j 1 dependency, including, critically, Xtend. This is critical because Xtend is the language in which the code generators are written. So as a next step, I'm going to try to remove the dependency in Xtend. After that, other dependencies such as MWE and MWE2 (the "Modeling Workflow Engine") also depend on it, and both Xtend and Xtext depend on MWE(2).

[emammoser]

Thank you for this update. It looks like you have a path forward, even if it is difficult. I wish we could say that we didn't need this improvement, but we recently received security scans that flags all instances of log4j1 as critical/severe.

Now that you have brought up Xtend, I remembered you stating in a different post that the version of Xtend that we use is partially the reason for the generator slowness and that there is a newer version that is "faster". Does this newer version have log4j2 or log4j1 dependencies? I do not want to increase the scope of this ticket to also upgrade Xtend unless it completely removed the log4j1 dependency

[eposse]

Well, it is not as simple as upgrading the Xtend version. The language (Xtend2) is actually different (from old Xtend). It has a different syntax, so it would require rewriting the generators. While doable, it is not trivial and would take time (weeks). Furthermore, Xtend2 still depends on log4j 1, so just upgrading wouldn't get us closer. So I would defer upgrading the code generators and deal with that in a separate issue later.

In any case, I need to patch both Xtend and Xtend2, because it turns out that we do use Xtend2 as well, mainly in some utilities.

So for now, let's stick with just patching all, both Xtend and Xtend2.

[emammoser]

Sounds good to me, thank you for the information

[eposse]

A status report:

I have now patched almost all of the Xtext plugins and features (I think I'm missing one), and all of the Xtend2 feature and plugins.

Next, finish any pending Xtext plugins, and patch the old Xtend 1 features and plugins.

[eposse]

Status report:

I've finished patching all Xtext, Xtend 1 and Xtend 2 features and plugins that used Log4j1 or JCL (which uses Log4j1).

Next in the list: Xpand.

[eposse]

An update.

Xpand was very small and simple and I've patched it.

I encountered a difficulty with part of "ECF" (the Eclipse Communications Framework).
One of the core Eclipse features "org.eclipse.equinox.p2.core" requires a features called "org.eclipse.ecf.filetransfer.httpclient5", which itself requires JCL (org.apache.commons.logging), which requires org.apache.log4j, i.e. Log4j 1.

This means that the requirement is at the very heart of Eclipse itself.

It looks like I was able to patch org.eclipse.ecf.filetransfer.httpclient5 as I have with other features. But being required by a core feature makes me a bit nervous. Fingers crossed, it will work.

Next, I've found that "Ant" (a Java Building tool) is required by many plugins, and it itself depends on Log4j1. I'm trying to patch that now, although that is a standalone plugin, without a feature to contain it, so I'm not sure how that will work. Hopefully it will.

[eposse]

I ran into difficulties building Ant, because itself is built in a very different way and has dependencies which I haven't been able to find.

I'm going to leave that on hold for a while and move onto a different component and circle back to it later.

[emammoser]

Is Ant itself installed with papyrus? Or just used to build other tools?

Either way, it is depressing to see that Eclipse and its foundational software isn't being maintained as much as we would have hoped. Log4j1 has been EOL since 2015.

[eposse]

Unfortunately Ant is installed with Papyrus. I'm not really sure why, but it is required by a lot of plugins, including some required directly by CX, like org.eclipse.emf.mwe.core.

I agree about the state of Eclipse and Papyrus updates. The only thing I can say about this is that it looks like the many projects that comprise Eclipse, such as Xtext and many, many more, do not have the capacity to make the updates, and, as the previous links I've provided suggest, the actual Log4shell vulnerability, which is the most famous, affected a version of Log4j 2 rather than Log4j 1, although Log4j 1 has its own vulnerabilities. So perhaps because of this, it has not been seen as a bigger priority by the different teams working on Eclipse projects. Also, some of these projects are not even Eclipse projects, like Ant.

I also think that when projects get too big, like many Eclipse projects, it becomes harder to upgrade dependencies as time passes. A component depends on another component, and then someone builds another to depend on it, and so on, so old dependencies linger for a long, long time. And since in this case the problem dependency was a logging library, it was considered low priority. But I think this sort of problem of legacy components lingering for a very long time, is not exclusive to Eclipse or Papyrus, but to software in general. As software becomes larger and more complex, it becomes more difficult to upgrade the older parts.

Anyway, today I'm working, not on OCL as I said, but on "Nebula", another set of plugins required by Papyrus. I decided to work on this one first, because it is smaller, just four plugins.

[eposse]

An update:

I successfully integrated Papyrus Compare and I continued testing. Code generation works as before. But during testing I found a bug when opening diagrams and the deployment editor. I am debugging this by comparing the behaviour in the old version (Papyrus 4.8) with the new one (Papyrus 6.5). I found a difference in the objects representing diagrams being created which is the cause of the bug, but I do not know yet why that happens. I continue investigating.

[eposse]

Just to give you another update:

The problem is related to architecture contexts and viewpoints. The code in Papyrus that handles these has changed drastically from 4.8 to 6.5. I'm still narrowing down the exact point where the problem originates. I have found a few places where this may be happening but I might need to contact the Papyrus developers.

[eposse]

A new update. I have been investigating problems related to the architecture context/viewpoints that arose during testing. I have fixed one that prevented the opening of the Deployment Editor, but there are others, preventing the creation and opening of standard UML diagrams, and resulting in an empty "New Diagram" pop-up menu. These are all related. I was able to create a minimalistic architecture model and tested it in plain Papyrus 6.5 and can confirm that the problems are with Papyrus, not with CX. I have been able to narrow down the Papyrus component responsible for this bug (it's the "Architecture Domain Merger" and happens when you open a Papyrus model for the first time during a session.) I am now in touch with the Papyrus developers to try to figure this out. I'll keep debugging it to see if I can patch it myself, rather than wait who knows how long before the Papyrus team fixes it.

PS: I'm off next week and I'll be back after New Year's.

[emammoser]

Thank you for the follow up. Hopefully this is something that can be resolved relatively quickly but keep us updated as you learn more.

[eposse]

A new update:

I was finally able to figure out the root cause of the bug. There is an bug in the algorithm that merges "Architecture Contexts" in Papyrus (not CX). I'm working on a solution, but it is not trivial, as this code impacts a lot of things that Papyrus does. But I have good reasons to think that I'll be able to fix it soon.

[emammoser]

Glad to hear it! Thank you for the update.

[eposse]

A status update: I have a solution that appears to work and seems to work on most cases, but there are still a couple of things that don't quite work, so I'll be digging into these. But I think I'm nearly done. Nevertheless, I think that we may need to migrate models, which is natural to expect considering we are jumping from Papyrus 4.8 to 6.5. But I think the migration rule would probably be relatively simple.

[eposse]

By the way, since we are making such a major version jump, perhaps we should also do a major version jump in CX from 2.6 to 3.0?

[emammoser]

I think it makes sense to do a major version jump to 3.0 personally. @J17359 thoughts?

[J17359]

Yes, 100% agree. Something this drastic should be a major version bump.

[eposse]

Sounds good. I'll update the version once I'm done fixing all the issues I've found with the patches.

[eposse]

I've finally resolved all the pending issues, and everything seems to be working well. I think it's ready for you to test. I'll just do a bit of code cleanup, start a build and let you know when it's ready for you to download.

[eposse]

Ok, the build is finally ready for you to test. You can get it in this link. I've tested it on AlmaLinux 8.9. Everything works as expected as far as I can see. No Log4J 1 to be seen. Only Log4J 2.17.1.

Note that the RPM still has version 2.6.0, but it is the right one, so you can test it. I'm now going to update the version to 3.0.0 as discussed in #490.

[eposse]

Closing as agreed with @j26151 by e-mail on February 26, 20024.