>People have had nearly a decade ... to remove COBOL from their apps. Seamless migration does not exist yet, and people have large apps that can't really be upgraded that easily. They would rather fork log4j and use their own fork.
>This is more akin to asking the JMeter team to support JMeter 2 Suppose: 1. someone asks to fix CVE in JMeter 1 2. they are eager to implement the fix 3. they provide a reasonable explanation why they can't upgrade I would expect: a) JMeter team to implement the fix b) or co-operate with getting the fix released (e.g. create Git branch, accept PRs, etc, prepare versions). c) or give away control over JMeter 1 so other contributors can implement 1.x fixes and release 1.x versions. For instance, option "c" might be selected by JMeter team if applying fixes and releasing takes too much effort. For example, if somebody adds GitHub Actions CI to JMeter 1.x I would be OK to review and merge it. Does that answer your question? >I would fully expect you to say move to the latest version where we have fixed this issue Note that we are about to release JMeter 5.5 with new features. The repository is all good for the release, however, the team did back-patch 5.4.2 Back-patching 5.4.2 was not my idea, and I appreciate the ones who did that (Milamber?) >I wouldn’t expect you to patch JMeter 2, 3, 4, and 5. JMeter 2 is not using log4j2, so it is not that impacted. We assume 5.x->5.4 upgrade is workable for everybody, and nobody voiced they are stuck with 5.0. I know people might be stuck with 4.x, and 3.x (that are affected by log4j2 CVE), so it would be responsible to release those versions as well. Unfortunately, 3.x and 4.x are Ant-based, so the release steps are way harder there than we have now. Vladimir
