>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
