Hello, When a free OSS library is publicly in EOL since many years, and you don’t pay extended support to anybody, you know the risks you’re taking.
As a software developer I am very frequently frustrated by people refusing the upgrade of libraries because it costs money and « doesn’t bring anything », so I will not contrubute to giving arguments to this policy. Fixing EOL library is just that IMO. If you want a fix, then you can pay for a project member or consultant to implement the fix and share it if you want with community on github without involving us, ASF allows that AFAIU. But you should not expect contributors of OSS project to do it on their free time , EOL has a meaning. Saying that, I wonder if we are explicit enough about EOL in JMeter. Regarding your comparison with Cobol is not free, and I am sure users pay lot of money for its « extended or not support », so it does not compare to log4j in any way. Now regarding a fix to jmeter 1 or 2, well it’s your opinion as of now, I am happy you’re contributing a lot these days, but things change as long as people. As of me, I would responsibly advise users to forget about Jmeter 1, 2, 3 not only for CVE but for all other bugs that have been fixed and all features in more up to date versions. We take time in our development to explicitly document deprecated features, changes… That helps upgrading. Regards Philippe On Tuesday, December 21, 2021, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >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 >
