What are the concerning security vulnerabilities in log4j 1 and the severity level?
I saw one mentioned in the thread which apparently redhat had fixed (with socket stream deserialization) On Mon, Dec 20, 2021 at 3:56 PM Martin Gainty <mgai...@hotmail.com> wrote: > i would ping the original author ceki gulcu > Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the > Apache model< > https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html > > > Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the > Apache model< > https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html > > > Brett Porter said.... I agree with Bertrand's point. Also, it is necessary > to be careful not to ascribe too much power to the votes themselves - they > are only a tool for gauging consensus, which is the main objective. > ceki.blogspot.com > > Best Regards, > martin- > > ________________________________ > From: Jungtaek Lim <kabhwan.opensou...@gmail.com> > Sent: Monday, December 20, 2021 4:26 PM > To: general@incubator.apache.org <general@incubator.apache.org> > Subject: Re: Looking for a champion: resurrect log4j 1.x > > Just wondering, is it even fulfilling the criteria of incubation? Have > there been any similar cases before? > > It was stated that there will be no effort on active development but focus > only on CVE fixes. This sounds to me as the project will start as only > fixing a few known CVEs and stop till other CVEs are discovered (there may > be huge difference between proactively discovering CVEs vs passively fixing > the reported CVEs by others), and never be attempted to become TLP. > Majority of status reports will be blank. That said, it doesn't seem that > sustainability is proven. > > > On Mon, Dec 20, 2021 at 10:51 PM John D. Ament <johndam...@apache.org> > wrote: > > > On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > 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. > > > > > > > Questions like this probably should be on one of the logging lists rather > > than the incubator list. The Incubator would not create a hostile fork > > under any circumstance, including of an existing project/sub-project > within > > Apache. In a situation like this it would be purely a call by the > Logging > > PMC, whether or not they want the Incubator to create the podling. > > > > > > > > > > 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 > > > > > > > > > > > > > > >
