You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Ralph Goers <ra...@dslextreme.com> on 2021/12/24 16:47:10 UTC
[DISCUSS] The future of Log4j 1.x
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
Re: [DISCUSS] The future of Log4j 1.x
Posted by Vladimir Sitnikov <si...@gmail.com>.
> 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
>allow development to continue, including bug fixes and enhancements
+1 to all that, including new source+binary releases as the changes are
merged.
On top of that, I would suggest dropping EOL notice and using something like
"Supported on best effort basis" or "Development ceased".
Vladimir
Re: [DISCUSS] The future of Log4j 1.x
Posted by Ralph Goers <ra...@dslextreme.com>.
Before any Pull Requests are reviewed this discussion needs to come to a conclusion.
So far I have seen some people in favor of option 1, none in favor of option 2, none in
favor of option 3, some in favor of option 1 or option 4, no one in favor of option 5
(with several -1s) and Vladimir who seems to be in favor of option 5 + more (whatever
that may be).
Other than Vladimir and Leo I am not sure who the other contributors are and am still
awaiting input from them.
In the meantime, we are still fighting fires in the Log4j 2 world and really have limited
time to review these PRs right now anyway.
Ralph
> On Dec 25, 2021, at 2:59 AM, Andrew Marlow <ma...@gmail.com> wrote:
>
> this is a great summary of the options. I vote for option 2.
>
> On Fri, 24 Dec 2021 at 16:47, Ralph Goers <ra...@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
>>
>>
>>
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
Re: [DISCUSS] The future of Log4j 1.x
Posted by Andrew Marlow <ma...@gmail.com>.
this is a great summary of the options. I vote for option 2.
On Fri, 24 Dec 2021 at 16:47, Ralph Goers <ra...@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
>
>
>
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
Re: [DISCUSS] The future of Log4j 1.x
Posted by Christian Grobmeier <gr...@apache.org>.
Thank you very much Ralph for compiling this list.
On Fri, Dec 24, 2021, at 17:47, Ralph Goers wrote:
> 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 am thinking option 1 is the best. We should improve log4j2 instead of wasting time to software which was last. updated in what, 2012?
However, I can see that there is some users who want to fix serious issues because they have reasons.
I would be fine with 2, if:
- we clearly mark it EOL and tell this is a security patch for those who still couldn't upgrade
- we promote to work on log4j2 bridge et al, if someone is willing to contribute, and helping writing migration guides
- we allow all commits which makes the build easier and fixes (critical) issues. No more features which could lead to a version bump to 1.3, which is already taken by a failed attempt to upgrade
I am OK with option 4. The build is to complicated for anybody outside the developer list to make it happen. If we upgrade, we need to help users further.
Here is a new option.
Assuming we can make it a 1.2.18 and assuming we find out there is >=2 people willing to develop this further by ~mid 2022, we vote again if we continue this project.
Only with a committed community we don't have to close it down again. Please take also in mind, that there is a competing logging project which developed the 1.2.x code base further. This will also add tensions.
Cheers
Christian
>
> 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
Re: [DISCUSS] The future of Log4j 1.x
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <ra...@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
>>
>>
>>
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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
>
>
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Christian Grobmeier <gr...@apache.org>.
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 <ck...@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
>> >
>> >
>> >
>>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Volkan Yazıcı <vo...@yazi.ci>.
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 <ck...@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
> >
> >
> >
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Carter Kozak <ck...@ckozak.net>.
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
>
>
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Dec 24, 2021, at 10:05 AM, Gary Gregory <ga...@gmail.com> wrote:
>
>>
>
> What happens to the new repo Ralph created, will it just be deleted?
>
The request was to delete that repo. The request was to rename apache/log4j to apache/logging-log4j1,
which is the same name as the repo I created.
Ralph
Re: [DISCUSS] The future of Log4j 1.x
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Dec 24, 2021 at 12:13 PM Carter Kozak <ck...@ckozak.net> wrote:
> > Sorry to be pedantic, but what Apache rules apply to the previous
> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
> > It should be telling, not ironic, that the last two contributors to
> Log4j 1 that are still here voted -1
>
> This is a great point which I hadn't realized myself. For what it's worth,
> I would consider _my_ vote with much less weight than those who have
> actually contributed to and maintained the log4j-1 project.
>
Let's not do that! ;-) Don't weigh your vote for not having had to suffer
through log4j 1 releases, DLLs and all ;-)
Gary
> -ck
>
> On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
> > On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers <ralph.goers@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
> > >
> > >
> > >
> >
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Christian Grobmeier <gr...@apache.org>.
On Fri, Dec 24, 2021, at 18:12, Carter Kozak wrote:
>> Sorry to be pedantic, but what Apache rules apply to the previous DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
>> It should be telling, not ironic, that the last two contributors to Log4j 1 that are still here voted -1
>
> This is a great point which I hadn't realized myself. For what it's
> worth, I would consider _my_ vote with much less weight than those who
> have actually contributed to and maintained the log4j-1 project.
There is no log4j1 or log4j2 community. There is only one ASF Logging community, which includes all committers from all the logging projects.
I have contributed to log4j1, but our votes weight the same. You are on the PMC because other PMC members trusted you, so do I. I trust you and believe your raise opinions to the best of the project.
We had this kind of discussion in our project history: "I had more commits, why doesn't it give me more weight in decisions". It almost killed this project years ago and led to many frustrations.
I hope I didn't sound like a teacher too much, but working here at that time made me very sensitive to this topic, so I had to write this.
Cheers!
>
> -ck
>
> On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
>> On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers <ra...@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
>> >
>> >
>> >
>>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Carter Kozak <ck...@ckozak.net>.
> Sorry to be pedantic, but what Apache rules apply to the previous DISCUSS/VOTE thread?
There's no need to apologize, the rules exist for a reason!
> It should be telling, not ironic, that the last two contributors to Log4j 1 that are still here voted -1
This is a great point which I hadn't realized myself. For what it's worth, I would consider _my_ vote with much less weight than those who have actually contributed to and maintained the log4j-1 project.
-ck
On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
> On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers <ra...@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
> >
> >
> >
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers <ra...@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
>
>
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Dec 24, 2021 at 5:21 PM Dominik Psenner <dp...@gmail.com> wrote:
> I am in favor of option 1, basically this:
>
> * Add an EOL marker, big and bold
> * Allow the repository to be cloned
> * Allow the repository to be forked
> * Disable the creation of new pull requests (on github)
> * Disable creation of issues (on github; this is the default; I want to
> stress this by mentioning it explicitly)
>
> My reasoning behind this is that an EOL must not consume resources. Any
> resource available should be invested in something that is not EOL so that
> opportunities are not lost with friction or distraction.
>
> Having this, someone can easily fork/clone the repository on github and
> work on the codebase. We may consider accepting these patches as
> contributions in the future. So long logging services considers log4j1 EOL,
> people should be strongly encouraged to migrate and not to base their work
> on an EOL component.
>
> Why not allow creation of pull requests or issues? This clearly draws a
> line. Logging services is not investing resources in an EOL component. This
> enforces that any new commits happen on a fork or clone. This has the
> effect that the public could not become confused. In the perception of the
> general public any changes are clearly unrelated to Apache logging
> services. The position of Apache logging services is clearly that the
> component is EOL.
>
> Should valuable contributions appear in the future we may reconsider what
> to do. We could then for instance review changes in a fork and cherry pick
> the contributions. This could hold for minimal changes that fix CVEs. If
> changes are too large to be cherry picked, my gut feeling tells me that too
> many resources are invested in an EOL component.
>
Nice write up Dominick & something I can get behind.
Gary
>
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Fri, Dec 24, 2021, 17:47 Ralph Goers <ra...@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
> >
> >
> >
>
Re: [DISCUSS] The future of Log4j 1.x
Posted by Dominik Psenner <dp...@gmail.com>.
I am in favor of option 1, basically this:
* Add an EOL marker, big and bold
* Allow the repository to be cloned
* Allow the repository to be forked
* Disable the creation of new pull requests (on github)
* Disable creation of issues (on github; this is the default; I want to
stress this by mentioning it explicitly)
My reasoning behind this is that an EOL must not consume resources. Any
resource available should be invested in something that is not EOL so that
opportunities are not lost with friction or distraction.
Having this, someone can easily fork/clone the repository on github and
work on the codebase. We may consider accepting these patches as
contributions in the future. So long logging services considers log4j1 EOL,
people should be strongly encouraged to migrate and not to base their work
on an EOL component.
Why not allow creation of pull requests or issues? This clearly draws a
line. Logging services is not investing resources in an EOL component. This
enforces that any new commits happen on a fork or clone. This has the
effect that the public could not become confused. In the perception of the
general public any changes are clearly unrelated to Apache logging
services. The position of Apache logging services is clearly that the
component is EOL.
Should valuable contributions appear in the future we may reconsider what
to do. We could then for instance review changes in a fork and cherry pick
the contributions. This could hold for minimal changes that fix CVEs. If
changes are too large to be cherry picked, my gut feeling tells me that too
many resources are invested in an EOL component.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Fri, Dec 24, 2021, 17:47 Ralph Goers <ra...@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
>
>
>