Guess there are 4 options: 1. resurrect log4j1 and let it die again 2. do a log4j1 release for the CVE under logging umbrella (as a subproject) - after all log4j1 belongs to logging as a subproject already ( https://logging.apache.org/dormant.html) 3. the log4j1-log4j2 bridge (but agree this is not a solution and requires to do 2 to be useful technically since none of log4j1 users will want to import log4j2, at least cause it is not compatible with java version or due to the injected bytecode like module-info) 4. do a CVE fix release fork on github or any other hosting
Personally I don't think 1 or 3 are real options, 4 is but not that nice indeed (due to the fact it would be yet another forks but also cause it requires some GAV change or build hack to be done properly) so from my window I would be tempted to push for 2 which sounds like a quick win for everyone. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 20 déc. 2021 à 14:32, John D. Ament <johndam...@apache.org> a écrit : > Hi Vladimir, > > I think based on what you're describing and the Logging PMC's response, > re-incubating the project makes sense. I would be curious if the Logging > PMC would be interested in restarting the sub-project after a successful > incubation period. This seems to match what Ralph is suggesting as well. > > Typically this would mean that the VP Logging PMC would serve as the > champion, and as the sponsor the Logging PMC would still be the one to vote > to add the project to the incubator. If the VP Logging isn't interested in > doing this, I would recommend starting out the project as a standalone > podling and keeping the Incubator as sponsor rather than Logging. See [1] > for some details on those notes. The incubator would be responsible for > voting on releases, receiving notices for new PPMC members, etc regardless > of who is the sponsor. Given enough contributors and a diverse contributor > base then the Incubator PMC and the Logging PMC (if they're the sponsor) > would vote whether everyone feels the new project can be brought back to > the Logging project. We can also decide as it gets closer to graduation to > move the podling into a sub-project if that's what everyone agrees. > > I would be up for helping you get through the incubator. If VP Logging > doesn't want to own the sponsorship part, I can be your Champion. > > John > > > [1]: https://incubator.apache.org/guides/proposal.html#background > > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > >Do you have "facts" (like message on mailing list) ? > > > > I am not sure what you mean. > > > > For example: > > > > 1) Ralph Goers says the existing committers did not touch 1.x code a lot: > > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n > > Ralph>Virtually all of the contributors to the Log4j 1.x project left a > few > > years before it was declared > > Ralph>EOL. That is the primary reason it was retired. Although the > current > > set of committers have > > Ralph>access to the code, none of us have ever built it > > > > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways > to > > move forward is to re-incubate log4j 1.x: > > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5 > > > > This in conjunction with #1 sounds like the current logging PMC is not > > interested in moving log4j 1.x forward. > > > > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the > > change; > > Gary Gregory (a member of Logging PMC) votes with -1 (binding): > > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8 > > > > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility > layer": > > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc > > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n > > > > I understand that log4j2 team might want everybody to upgrade to 2.x, > > however, that is not possible since the apps would need significant > > regression testing, > > the compatibility layer is far from perfect, and so on. > > Many apps are fine with 1.x, and they do not need 2.x features. > > There's no reason to upgrade, so I am not interested in investing time in > > improving > > the compatibility layer. > > > > Is it what you ask? > > > > Vladimir > > >
