Re: [DISCUSS][VOTE] Future of Log4j 1.x
Hi Leo, good new year to you! On Sun, Jan 2, 2022, at 07:12, Leo Simons wrote: > Hey, > > Happy new year everyone! > > On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers > wrote: > >> Leo seemed interested at first but didn’t weigh in on the discussion >> thread. > > > I'm here. I did mention in a couple mails I'd be away. Real life happens :). > > I think I made clear what I am interested in through several emails and in > code. > I've also pointed out what I wouldn't do (like step up as a maintainer on a > permanent basis, or incubate something). I think you are very welcome at this place and no matter the outcome of this vote, let us discuss how you can still find an open source home here. I know you have a different opinion, but learning more about Log4j1 I think a person with your skills and dedication is more than welcome in working with log4j 1 migration. cheers! > I think all the relevant arguments on how to proceed with 1.x have been > made (a few times...). > I don't have anything new to add. > I'll accept the vote outcome. > > > Cheers! > > > Leo
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Hey, Happy new year everyone! On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers wrote: > Leo seemed interested at first but didn’t weigh in on the discussion > thread. I'm here. I did mention in a couple mails I'd be away. Real life happens :). I think I made clear what I am interested in through several emails and in code. I've also pointed out what I wouldn't do (like step up as a maintainer on a permanent basis, or incubate something). I think all the relevant arguments on how to proceed with 1.x have been made (a few times...). I don't have anything new to add. I'll accept the vote outcome. Cheers! Leo
[DISCUSS][VOTE] Future of Log4j 1.x
Discussion shouldn’t happen on the main vote thread please. Users are certainly free to use Logback. If they are OK with losing log events during reconfiguration and using a framework that is maintained by one person and are OK when he disappears for a year and a half that is their choice. Please remember, this is not a commercial venture. No Java logging framework is. Switching to Logback also requires work. It doesn’t natively support Log4j 1 configuration files. Log4j 2 does support Log4j 1 configuration using the Log4j 1.2 bridge, which we are constantly improving. But the bottom line is that I would prefer that users migrate to Logback over sticking with Log4j 1. Although it has many of Log4j 1’s flaws it does not suffer from the multi-threading issues that Log4j 1 has. Of course, I think Log4j 2 is a better choice, but I am obviously biased. Happy New Year! Ralph > On Jan 1, 2022, at 8:40 AM, Xeno Amess wrote: > > +0 > >> People should migrate to log4j2. > good thinking, but what if they migrate to logback... > IMO logback is a thing more likely log4j1 than log4j2, just user side. > > > Ralph Goers 于2022年1月1日周六 23:18写道： > >> +1 to Option 1 >> >> Ralph >> >>> On Dec 29, 2021, at 12:33 PM, Christian Grobmeier >> wrote: >>> >>> Hello, >>> >>> as discussed in another thread, this is a vote about the future of log4j >> 1. This vote stays open for the usual 72h. >>> Options are explained below. >>> >>> You can vote for: >>> >>> [ ] +1, Option 1 >>> [ ] +1, Option 2 >>> [ ] +/- 0, abstain >>> [ ] -1 object against those options >>> >>> Option 1: Create a README.md that publishes the projects EOL status and >> do nothing else. >>> Option 2: Create a README which says the project is EOL but allow the >> following work for 1.2.18 AND create a full release: >>> 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 >>> >>> Regards, >>> Christian >>> -- >>> The Apache Software Foundation >>> V.P., Data Privacy >>> >> >>
Re: [DISCUSS][VOTE] Future of Log4j 1.x
These show up as two distinct threads In Mail on my MacBook Pro. FWIW, the PMC is aware of at least two distributions that already seem to fulfill the need of providing patched versions of Log4 1: 1. https://github.com/albfernandez/log4j/ 2. https://search.maven.org/artifact/io.confluent/confluent-log4j (The source appears to be in a private repository). Of course, both of these use different maven coordinates than Apache Log4j so users will have to ensure they exclude the Apache Log4j dependencies. Ralph > On Dec 30, 2021, at 5:23 AM, Vladimir Sitnikov > wrote: > > Christian>vote in this thread, which is, btw not meant for discussion but > for voting. > > We are on a [DISCUSS] thread (check the subject). > > Ralph "created" [DISCUSS] thread by hitting "reply" and changing the > subject. > "reply" keeps message-id, so it might look like a single thread. > > See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j > 1.x" > at https://lists.apache.org/list.html?dev@logging.apache.org > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Christian>vote in this thread, which is, btw not meant for discussion but for voting. We are on a [DISCUSS] thread (check the subject). Ralph "created" [DISCUSS] thread by hitting "reply" and changing the subject. "reply" keeps message-id, so it might look like a single thread. See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j 1.x" at https://lists.apache.org/list.html?dev@logging.apache.org Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
If there is long term commitment apart from these urgent fixes we can run another vote. You cannot guarantee you are alive by February, nobody can give such guarantees. The logging pmc is not here to accept all patches as they come in but to make decisions best to the project (among other duties). Once there is a mandate and consent among pmc we most likely try to review and comment on the prs coming in. No guarantees though your pr will be accepted as it is. That said, we continue to vote in New committers and pmc members as we always have. Prerequisites to become logging committer is long term interest in logging and understanding the ASF way. Also, I daresay, many people here like to add new people when they are adding positive attitude (versus toxic behavior). I hope all your questions are clarified now and we can continue to discuss (see Ralph's message) on slack and vote in this thread, which is, btw not meant for discussion but for voting. -- The Apache Software Foundation V.P., Data Privacy On Wed, Dec 29, 2021, at 21:41, Vladimir Sitnikov wrote: >>Log4j is owned by the Logging Services PMC. You cannot incubate it without > this PMC’s approval. > > Exactly. As far as I understand, Logging pmc should accept patches and > release fixes or they should approve reincubating. > Of course, you can try rejecting patches and disapprove reincubation, > however, that won't hold water. > > Unfortunately, I have not seen the response from the logging pmc regarding > approve/disapprove re-incubating. There's a pending question to Ron still. > > I do not consider forks outside of the ASF. > >>But I notice the one topic you did not respond to was the lack of > interested people other than yourself. Why is that? > > I find the question irrelevant, and I find it has nothing to do with > accepting patches and releasing 1.2 > I belive there were even people on incubator thread, so it is strange why > do you demand that I provide you with a list of rock-star 1.x maintainers. > > 1) I can't guarantee I will be alive in February. Can you guarantee all the > logging pmc members will be alive then? I doubt so. So I find that > questions like "how can we be sure you will send patches" too intimate. > > 2) I have already filed a patch for buildscripts. Whould you review it and > merge? > > 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support > 1.2. What do you do then? Would you add all of them to the logging pmc? > I don't really see the point why do you ask, and at the same time I can't > guarantee the people I gather will be alive tomorrow. I can't guarantee > they will always have interest in 1.2 > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Makes sense. I will close thus vote not earlier than Jan 5, if there is no further objections. Thanks for your input Tim -- The Apache Software Foundation V.P., Data Privacy On Thu, Dec 30, 2021, at 01:56, Tim Perry wrote: > I propose that this vote should stay open longer than 72 hours given > that we are coming up on New Years and many people who would wish to > weigh in might be on vacation right now. > > Tim > >> On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: >> >> Consistent contributors are frequently invited to be committers and later >> PMC members. Having at least three people maintaining anything is an Apache >> standard for maintaining vendor neutrality, ensuring a minimum number of >> people can verify release candidates to address security issues or any other >> releases. >> >> — >> Matt Sicker >> >>> On Dec 29, 2021, at 14:41, Vladimir Sitnikov >>> wrote: >>> >>> Log4j is owned by the Logging Services PMC. You cannot incubate it without >>> this PMC’s approval. >>> >>> Exactly. As far as I understand, Logging pmc should accept patches and >>> release fixes or they should approve reincubating. >>> Of course, you can try rejecting patches and disapprove reincubation, >>> however, that won't hold water. >>> >>> Unfortunately, I have not seen the response from the logging pmc regarding >>> approve/disapprove re-incubating. There's a pending question to Ron still. >>> >>> I do not consider forks outside of the ASF. >>> But I notice the one topic you did not respond to was the lack of >>> interested people other than yourself. Why is that? >>> >>> I find the question irrelevant, and I find it has nothing to do with >>> accepting patches and releasing 1.2 >>> I belive there were even people on incubator thread, so it is strange why >>> do you demand that I provide you with a list of rock-star 1.x maintainers. >>> >>> 1) I can't guarantee I will be alive in February. Can you guarantee all the >>> logging pmc members will be alive then? I doubt so. So I find that >>> questions like "how can we be sure you will send patches" too intimate. >>> >>> 2) I have already filed a patch for buildscripts. Whould you review it and >>> merge? >>> >>> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support >>> 1.2. What do you do then? Would you add all of them to the logging pmc? >>> I don't really see the point why do you ask, and at the same time I can't >>> guarantee the people I gather will be alive tomorrow. I can't guarantee >>> they will always have interest in 1.2 >>> >>> Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
+1, Option 1 People should migrate to log4j2. On Thu, 30 Dec 2021 at 01:56, Tim Perry wrote: > I propose that this vote should stay open longer than 72 hours given that > we are coming up on New Years and many people who would wish to weigh in > might be on vacation right now. > > Tim > > > On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: > > > > Consistent contributors are frequently invited to be committers and > later PMC members. Having at least three people maintaining anything is an > Apache standard for maintaining vendor neutrality, ensuring a minimum > number of people can verify release candidates to address security issues > or any other releases. > > > > — > > Matt Sicker > > > >> On Dec 29, 2021, at 14:41, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> > >> > >>> > >>> Log4j is owned by the Logging Services PMC. You cannot incubate it > without > >> this PMC’s approval. > >> > >> Exactly. As far as I understand, Logging pmc should accept patches and > >> release fixes or they should approve reincubating. > >> Of course, you can try rejecting patches and disapprove reincubation, > >> however, that won't hold water. > >> > >> Unfortunately, I have not seen the response from the logging pmc > regarding > >> approve/disapprove re-incubating. There's a pending question to Ron > still. > >> > >> I do not consider forks outside of the ASF. > >> > >>> But I notice the one topic you did not respond to was the lack of > >> interested people other than yourself. Why is that? > >> > >> I find the question irrelevant, and I find it has nothing to do with > >> accepting patches and releasing 1.2 > >> I belive there were even people on incubator thread, so it is strange > why > >> do you demand that I provide you with a list of rock-star 1.x > maintainers. > >> > >> 1) I can't guarantee I will be alive in February. Can you guarantee all > the > >> logging pmc members will be alive then? I doubt so. So I find that > >> questions like "how can we be sure you will send patches" too intimate. > >> > >> 2) I have already filed a patch for buildscripts. Whould you review it > and > >> merge? > >> > >> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to > support > >> 1.2. What do you do then? Would you add all of them to the logging pmc? > >> I don't really see the point why do you ask, and at the same time I > can't > >> guarantee the people I gather will be alive tomorrow. I can't guarantee > >> they will always have interest in 1.2 > >> > >> Vladimir > -- Dominik Psenner
Re: [DISCUSS][VOTE] Future of Log4j 1.x
I propose that this vote should stay open longer than 72 hours given that we are coming up on New Years and many people who would wish to weigh in might be on vacation right now. Tim > On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: > > Consistent contributors are frequently invited to be committers and later > PMC members. Having at least three people maintaining anything is an Apache > standard for maintaining vendor neutrality, ensuring a minimum number of > people can verify release candidates to address security issues or any other > releases. > > — > Matt Sicker > >> On Dec 29, 2021, at 14:41, Vladimir Sitnikov >> wrote: >> >> >>> >>> Log4j is owned by the Logging Services PMC. You cannot incubate it without >> this PMC’s approval. >> >> Exactly. As far as I understand, Logging pmc should accept patches and >> release fixes or they should approve reincubating. >> Of course, you can try rejecting patches and disapprove reincubation, >> however, that won't hold water. >> >> Unfortunately, I have not seen the response from the logging pmc regarding >> approve/disapprove re-incubating. There's a pending question to Ron still. >> >> I do not consider forks outside of the ASF. >> >>> But I notice the one topic you did not respond to was the lack of >> interested people other than yourself. Why is that? >> >> I find the question irrelevant, and I find it has nothing to do with >> accepting patches and releasing 1.2 >> I belive there were even people on incubator thread, so it is strange why >> do you demand that I provide you with a list of rock-star 1.x maintainers. >> >> 1) I can't guarantee I will be alive in February. Can you guarantee all the >> logging pmc members will be alive then? I doubt so. So I find that >> questions like "how can we be sure you will send patches" too intimate. >> >> 2) I have already filed a patch for buildscripts. Whould you review it and >> merge? >> >> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support >> 1.2. What do you do then? Would you add all of them to the logging pmc? >> I don't really see the point why do you ask, and at the same time I can't >> guarantee the people I gather will be alive tomorrow. I can't guarantee >> they will always have interest in 1.2 >> >> Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Consistent contributors are frequently invited to be committers and later PMC members. Having at least three people maintaining anything is an Apache standard for maintaining vendor neutrality, ensuring a minimum number of people can verify release candidates to address security issues or any other releases. — Matt Sicker > On Dec 29, 2021, at 14:41, Vladimir Sitnikov > wrote: > > >> >> Log4j is owned by the Logging Services PMC. You cannot incubate it without > this PMC’s approval. > > Exactly. As far as I understand, Logging pmc should accept patches and > release fixes or they should approve reincubating. > Of course, you can try rejecting patches and disapprove reincubation, > however, that won't hold water. > > Unfortunately, I have not seen the response from the logging pmc regarding > approve/disapprove re-incubating. There's a pending question to Ron still. > > I do not consider forks outside of the ASF. > >> But I notice the one topic you did not respond to was the lack of > interested people other than yourself. Why is that? > > I find the question irrelevant, and I find it has nothing to do with > accepting patches and releasing 1.2 > I belive there were even people on incubator thread, so it is strange why > do you demand that I provide you with a list of rock-star 1.x maintainers. > > 1) I can't guarantee I will be alive in February. Can you guarantee all the > logging pmc members will be alive then? I doubt so. So I find that > questions like "how can we be sure you will send patches" too intimate. > > 2) I have already filed a patch for buildscripts. Whould you review it and > merge? > > 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support > 1.2. What do you do then? Would you add all of them to the logging pmc? > I don't really see the point why do you ask, and at the same time I can't > guarantee the people I gather will be alive tomorrow. I can't guarantee > they will always have interest in 1.2 > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
>Log4j is owned by the Logging Services PMC. You cannot incubate it without this PMC’s approval. Exactly. As far as I understand, Logging pmc should accept patches and release fixes or they should approve reincubating. Of course, you can try rejecting patches and disapprove reincubation, however, that won't hold water. Unfortunately, I have not seen the response from the logging pmc regarding approve/disapprove re-incubating. There's a pending question to Ron still. I do not consider forks outside of the ASF. >But I notice the one topic you did not respond to was the lack of interested people other than yourself. Why is that? I find the question irrelevant, and I find it has nothing to do with accepting patches and releasing 1.2 I belive there were even people on incubator thread, so it is strange why do you demand that I provide you with a list of rock-star 1.x maintainers. 1) I can't guarantee I will be alive in February. Can you guarantee all the logging pmc members will be alive then? I doubt so. So I find that questions like "how can we be sure you will send patches" too intimate. 2) I have already filed a patch for buildscripts. Whould you review it and merge? 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support 1.2. What do you do then? Would you add all of them to the logging pmc? I don't really see the point why do you ask, and at the same time I can't guarantee the people I gather will be alive tomorrow. I can't guarantee they will always have interest in 1.2 Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
You are a member of 2 ASF projects yet you don’t understand how the ASF works? Log4j is owned by the Logging Services PMC. You cannot incubate it without this PMC’s approval. You can certainly fork it outside the ASF but you cannot call it Log4j as the ASF owns the trademark. Sonatype would be unlikely to accept such a project with different maven coordinates that overlaps the log4j package naming as it would create a dependency mess. But I notice the one topic you did not respond to was the lack of interested people other than yourself. Why is that? Ralph > On Dec 29, 2021, at 1:05 PM, Vladimir Sitnikov > wrote: > > If you are not interested in maintaining 1.x, please give it away (to > another pmc or add pmc members) and that is it. > > Even if you all vote for option 1, then I would just reincubate 1.x or find > an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point > of this vote then? You can't really prevent 1.2.18, 1.2.19, ... > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
If you are not interested in maintaining 1.x, please give it away (to another pmc or add pmc members) and that is it. Even if you all vote for option 1, then I would just reincubate 1.x or find an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point of this vote then? You can't really prevent 1.2.18, 1.2.19, ... Vladimir
[DISCUSS][VOTE] Future of Log4j 1.x
What “People”. So far you are the only person who seems interested. Leo seemed interested at first but didn’t weigh in on the discussion thread. AFAIK that’s it. Two people does not make a community. Furthermore, Log4j 1 was declared EOL 6 years ago and has been unsupported for 9 years. It will remain EOL until the PMC says otherwise. Ralph > On Dec 29, 2021, at 12:46 PM, Vladimir Sitnikov > wrote: > > -1 as it is invalid to say the project is "end of life" provided there are > people willing to support it. > > Vladimir
Re: [DISCUSS] The future of Log4j 1.x
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 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
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 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
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 wrote: > > this is a great summary of the options. I vote for option 2. > > On Fri, 24 Dec 2021 at 16: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 >> >> >> > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk
Re: [DISCUSS] The future of Log4j 1.x
this is a great summary of the options. I vote for option 2. On Fri, 24 Dec 2021 at 16: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 > > > -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk
Re: [DISCUSS] The future of Log4j 1.x
On Fri, Dec 24, 2021 at 5:21 PM Dominik Psenner 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 > 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
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 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
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 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 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
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 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
> On Dec 24, 2021, at 10:05 AM, Gary Gregory 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
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
>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
On Fri, Dec 24, 2021 at 12:13 PM 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. > 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 > > > 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
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 >> 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
> 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 > 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
On Fri, Dec 24, 2021 at 11:47 AM 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. 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
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 > > >
[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
