If I were to vote today it would probably be for option 1. I had a discussion with another ASF member yesterday who reminded me that in projects like Tomcat EOL means EOL. Once that date is hit under no circumstances will they issue a new release.
However, I understand that there is a difference between Log4j and Tomcat. Tomcat 4 vs 5 would not have been a completely new and incompatible architecture as Log4j 2 was. On the other hand I created the compatibility bridge 2 years ago and it is quite clear that some of the people looking to fix Log4j 1 have no idea it exists and/or have never tried it. My preference would be to focus on fixing whatever issues are found in that. Options 2 & 3 are interesting because they indicate that the project is still EOL. But they don’t really help anyone much. So if any work is done on the Log4j 1 code base I would generally agree that option 4 is the best choice. I am also -1 on option 5. If option 4 is chosen it is possible I could be persuaded to do another CVE release should one be necessary, but that is it. Log4j 1 is EOL and should stay that way. Ralph > On Dec 24, 2021, at 9:47 AM, Ralph Goers <[email protected]> wrote: > > As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 was > released on May 26, 2012. The last commit was to update the > web site 7 years ago. The changes.xml file shows there were commits up to > sometime in 2012, all of which were performed by Gary Gregory > and Christian Grobmeier who ironically both voted no to opening the repo back > up. > > The point of this history is to point out that the project essentially died > in 2012. We simply acknowledged it in 2015. > > So now we have voted to open the repo. The question then becomes what to do > next and going forward. I see several options: > > 1. Create a README.md that publishes the projects EOL status and do nothing > else. > 2. Create a README.md that says the project is EOL and no further big fixes > or enhancements will be made but 1.2.18 was a special > circumstance. Perform ONLY the following work for 1.2.18: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > The expectation is that the above would address the actual issues and not > just remove classes. > Do NOT perform a release of any kind. > 3. Option 2 but only perform a source release. > 4. Option 2 but perform a full release. > 5. Option 4 but allow development to continue, including bug fixes and > enhancements. > > I personally can see valid reasons to do any of the above. I have my own > opinion on this but I will post that in a reply to this discussion kickoff. > > If you have other proposals feel free to state them. > > This discussion will be followed up by a vote thread if necessary. > > Ralph > > >
