I’m sorry, I was just directed to this thread. I don’t read my incubator emails every day since I am not mentoring any podlings at the moment.
There seems to be some disconnect with the facts. From my viewpoint they are: An email came in asking if it would be possible to put out a new 1.2.18 release to address the outstanding CVEs. Our response was that we were totally focused on 2.x, don’t have a lot of experience building 1.x but would be happy to help release that if it met the PMCs expectations. A pull request then arrived - I believe https://github.com/apache/log4j/pull/16 - that was objected to by one of our PMC members as it deletes a bunch of classes rather than fixing them in a manner similar to what we did for Log4j 2. I noticed that there seemed to be a disconnect between some of the posters. Some just wanted to get 1.2.18 published as originally proposed while others seemed to want it to continue on. As there currently is no Log4j 1 community I asked which option they were after and suggested that if they wanted to develop a community that the incubator is where that happens with Logging Services as the sponsor. If a community develops it would be expected that graduation would be as a subproject of the Logging Services Project. That seemed to make some unhappy as any PMC member could veto commits in the Log4j 1 work. As far as I am concerned we never really got an answer to 1) Is this a one and done? 2) Is there are real community to support Log4j 1? 3) There are major flaws in Log4j 1.x’s architecture which is why SLF4J/Logback and Log4j 2 came to be. Will an attempt be made to address those without breaking compatibility? 4) Does this community care about compatibility? Simply removing classes is not user friendly. To top it off this discussion was going on while the whole Logging Services PMC was overwhelmed with security emails, users asking for help, and the PMC trying to get patch releases out. It was a poor choice of timing to try to have this discussion during that frenzy. In short, we don’t object to either a 1.2.18 release or reactivating Log4j 1. What we don’t want is a release of Log4j 1 along with a misconception that it is being supported again when it is not. We don’t want releases of Log4j 1 that do more harm than good. Sorry for the long post. Ralph > On Dec 20, 2021, at 12:26 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Hi, > > I want to resurrect log4j 1.x to fix well-known security issues. > I'm looking for the champion and committers. > > log4j 1.x is a wildly used logging library, so releasing a secured version > would silence CVE warnings > all over the world, and it would enable users to focus on more relevant > tasks than "upgrading from log4j1 to log4j2". > > I do not expect active log4j1 development, however, I would strongly focus > on fixing the security issues. > > Unfortunately, there are lots of applications that can't easily upgrade to > log4j2, and they are exposed to security issues. > I did try my best cooperating with the current logging PMC, and it looks > like they > are not interested in fixing 1.x (see [1], [2], [3], [4]) > > I'm a member of PMC on Apache JMeter and Apache Calcite projects, so > I am familiar with the way Apache projects are governed. > > [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5 > [2]: https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc > [3]: https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n > [4]: https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8 > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
