I’d be in favor of 1 or 4. Option 5 isn’t very feasible right now evidenced by how difficult it is to get enough votes on most of our other subproject releases like log4net, log4cxx, Log4j Scala API, and Log4j Kotlin API. There’s a long history in this PMC of wondering whether or not to continue developing various subprojects due to lack of community activity. -- Matt Sicker
> On Dec 24, 2021, at 12:30, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 <ralph.go...@dslextreme.com> 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 >> >> >> >
