Virtually all of the contributors to the Log4j 1.x project left a few years before it was declared EOL. That is the primary reason it was retired. Although the current set of committers have access to the code, none of us have ever built it. My understanding is it requires an extremely old JDK.
If you have people who know how to build it they would be welcome to do so. The PMC would still have to vote on it and actually release it. Ralph > On Dec 14, 2021, at 7:09 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Hi, > > I hope log4j finds you well :) > I know log4j 1.x has reached its end of life long ago, > however, I wonder if there's a possibility to ship 1.2.18 with > "network-related" classes removed. > > The list of classes I suggest removing: > * JMSAppender: it looks like it might cause "remote code execution" issues > if an attacker can modify the logging configuration. > Frankly speaking, I would just remove the appender and what for what > happens. > * JMSSink, SocketServer, SocketNode, chainsaw: if somebody needs them, they > can use 1.2.17 > > A slightly better option would be moving the extra features to an extra > jar, however, it would require more effort, and I am not sure it is worth > doing. > > My motivation is as follows: > * Everybody has questions on "what to do with log4j 1.x" > * There are applications that can't replace log4j 1 with 2 (e.g. they use > programmatic configuration) > * The maintenance overheads for releasing 1.2.18 do not seem to be severe. > At the end of the day, I suggest removing several classes and releasing it > * Dependabot would be able to bump log4j:log4j from 1.2.17 to 1.2.18 > > That is why I think releasing 1.2.18 as a "security hardened" version would > be good for everybody. > > I think I can create a PR for the change, however, I can't really release > it without logging PMC. > > WDYT? > > See https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513 > > Vladimir