I am going to set up a vote for option 1 and 4. I think we have this thread open for a long time already and don't expect many other responses
-- The Apache Software Foundation V.P., Data Privacy On Wed, Dec 29, 2021, at 07:55, Volkan Yazıcı wrote: > Agreed with all points of Carter. > > It is either 1 or 4. > Anything more than 4 (including 5) is a hard no from me. > > On Fri, Dec 24, 2021 at 6:00 PM Carter Kozak <cko...@ckozak.net> wrote: > >> I would agree directionally with option 1 or option 4. >> >> Making changes without pushing binary artifacts to maven central (options >> 2 and 3) is unlikely to do much good for the types of projects which still >> use log4j1. Option 5 is a hard no from me, my time is already too >> constrained, there are better options, and the architecture limits >> substantive improvements. >> >> -ck >> >> On Fri, Dec 24, 2021, at 11:47, Ralph Goers 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 >> > >> > >> > >>
