To be fair to the log4j team, version 1.12.x went into maintenance mode back in 2007 and they did a couple of minor updates in 2010 and 2012.
People have had nearly a decade since the last maintenance release to remove this old dependency and plan/implement an upgrade to the 2.x.x releases. This is more akin to asking the JMeter team to support JMeter 2. I would fully expect you to say move to the latest version where we have fixed this issue, I wouldn’t expect you to patch JMeter 2, 3, 4, and 5. How long should something that is dead be supported? > On 21 Dec 2021, at 10:48, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > >> would you be happy >> to see our users abandon JMeter because a CVE is discovered >> but it can happen to any >> project (logback also had one although less impacting) > > Consider a case: > 1. A critical vulnerability is discovered in JMeter 3.0 (e.g. remote code > execution via HTTP client) > 2. Multiple users report the issue and mention they can't upgrade from 3.0 > to the more recent versions and provide reasons > 3. (optional) some users might even suggest their help or patches fix the > issue > 3. JMeter team says "you are using a too old version, you must upgrade; > patches on 3.0 are not accepted anymore" > > If that really happens, I expect the users would stop trusting the JMeter > team. > > ---- > > This is exactly what happens with log4j: > > 1. Critical vulnerability is discovered in log4j 1.x and 2.x > 2. Multiple users report the issue and mention they can't upgrade from > log4j 1.x to 2.x (too big scope of regression, incompatible configuration > files, incompatible APIs) > 3. Multiple users suggest patches for fixing log4j 1.x > 4. log4j team says "you must upgrade to 2.x; patches for 1.x are not > accepted anymore; by the way, you can't become log4j 1.x committer also" > > That is a red flag to me. > > I believe, the teams should either maintain the versions (e.g. keep fixing > CVEs), or they should be open > to give away the maintenance rights to the ones who are willing to do the > maintenance. > > It turns out, log4j team fails here. They do not allow others to touch 1.x, > and they ignore it themselves. > >> does not bring major features to users (I >> think logging works pretty nicely today), > > Of course. I expect logback to be more secure and predictable in the long > run. > > What I dislike the most is that message processing was added to log4j2 as a > feature. > Does that belong to a logger? Of course, not. > > I expect log4j2 might get more "silent features" of that kind. > > The second point is that the current set of committers for log4j team > ignores 1.x. > Even though I understand everybody's time is limited, they ignore > user requests, > and they effectively deny contributions. > > See https://lists.apache.org/thread/6lhkyytvpg4md757tfydb1k0mmp5j1oc > > So the key reason for getting rid of log4j is not the specific CVE. > The key reason is I do not really trust the team behind log4j2 for the > reasons above. > > Frankly speaking, I have no idea what to do with old JMeter releases like > 3.x, and 4.x. > It might be very well that case we should release fixes for the past > releases as well. > The workaround of "replacing jars" or "cutting class files" is hard to > maintain and control for the users. > > I really fear asking Milamber to do the releases that since I expect old > code might fail to even compile. > However, I am sure there are a lot of users who still use JMeter 3.x. > For instance, if JMeter 3.x features are just enough, why upgrade and get > accidental issues? > I can try releasing 3.x, 4.x branches though. > > Vladimir
