On Fri, Dec 24, 2021 at 11: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.
Note that the repo DISCUSS/VOTE thread seemed informal because it did
specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow RELEASE
rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
what Apache rules apply to the previous DISCUSS/VOTE thread?
It should be telling, not ironic, that the last two contributors to Log4j 1
that are still here voted -1, but, if, big if, we (1) move fw the repo and
(2) then w a release... I'll opine ;-)
>
>
> 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:
>
What happens to the new repo Ralph created, will it just be deleted?
>
> 1. Create a README.md that publishes the projects EOL status and do
> nothing else.
>
Fine with me.
> 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.
>
If we move fw w the repo, this seems like a no-brainer requirement IMO.
> b. Fix the Java version bug.
>
Not sure what that one is, but If we move fw w the repo, OK.
c. Fix CVE-2021-4104 (expanded to address all JNDI components)
>
If we move fw w the repo, OK
> d. Fix CVE-2019-17571
> The expectation is that the above would address the actual issues and
> not just remove classes.
>
If we move fw w the repo, OK.
> 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.
>
Seems like the better solution b/w 3 and 4, a source only feels like a
tease if not worse.
> 5. Option 4 but allow development to continue, including bug fixes and
> enhancements.
>
-1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.
Thank you Ralph but putting this list together! :-)
Gary
>
> 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
>
>
>
