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
> 
> 
> 

Reply via email to