I'm not opposed to moving faster, but just to be clear, none of those CVEs look like they affect ZK's use of log4j1.2 at all.
* The use of Chainsaw is optional for users. To avoid the vulnerability, they can just not use it. * The XML entities issue would require users to put vulnerable config files on their class path. * The SQL injection vulnerability would require users to configure the JDBC Appender, which ZK doesn't configure in its example configs by default, so a user would specifically have to choose to use those vulnerable optional pieces. I just don't want the project to rush and make mistakes, based on panic, when there's no need to. I do think these are more good reasons to adopt something that is current and actively maintained, though, rather than something that is old and not active. On Tue, Jan 18, 2022 at 12:11 PM Enrico Olivelli <eolive...@gmail.com> wrote: > Il giorno mar 18 gen 2022 alle ore 18:09 Andor Molnar > <an...@apache.org> ha scritto: > > > > Thanks for the feedback Enrico / Christopher. > > > > CVEs have been popping up recently for log4j1: > > > > - CVE-2022-23305 Log4j v1 - SQL injection in JDBC Appender > > - CVE-2022-23306 Log4j v1 - Ability to send local files to remote > locations via XML entities in log4j.xml > > - CVE-2022-23307 A deserialization flaw in the Chainsaw component of > Log4j 1 can lead to malicious code execution. > > To whom who is interested there are some discussions about resuming > log4j1 project (in the Apache incubator), also current users could > probably use reload4j fork > > > > > Which pushes us to move off from log4j1 sooner rather than later. > Considering the options and the work I’ve already done on this front, I > would stick with ‘logback’ as the default logging backend for ZooKeeper and > will get my patch in a good shape for submission asap. We can talk about > creating a new wiki page for the deployment/runtime options for logging > backends afterwards. > > +1 let's do this ASAP > > Enrico > > > > > Andor > > > > > > > > > On 2022. Jan 14., at 13:54, Christopher <ctubb...@apache.org> wrote: > > > > > > On Fri, Jan 14, 2022 at 1:24 AM Enrico Olivelli <eolive...@gmail.com> > wrote: > > > > > >> Il Gio 13 Gen 2022, 09:48 Andor Molnar <an...@apache.org> ha scritto: > > >> > > >>> Providing sample configs for logging backends which we don’t actively > > >>> maintain. I don’t this is gonna work. Maybe log4j.properties is > already > > >>> broken too in some parts, because we don’t have test coverage / > active > > >> user > > >>> base for that. Sounds to me a waste of effort and error-prone > practice. > > >> > > > > > > > > > Things like that, if done at all, are best suited to blog posts that > > > explain "this is what I did to make this work; it may work for you". > Blog > > > posts in a feed on the website can communicate useful user experience > > > stories that may help others, but it's okay if they get out of date, > since > > > they don't have to be actively maintained documentation. > > > > > > > > > > > >>> > > >>> Using a more powerful backend for tests that we ship with our product > > >>> neither makes sense to me. What would be the cons for the maintainers > > >> than > > >>> using a single solution end-to-end? > > >>> > > >> > > >> > > > > > > The same cons for any dependency with increased complexity: increased > risk > > > of failure, vulnerabilities, etc. These risks are more important in > > > production than they are in the build/test environment. But, I'm not > going > > > to champion using a separate implementation for tests than what is > shipped > > > in the tarball. I just wanted to explain that it was possible to do > that, > > > if you wanted. > > > > > > > > > > > >> At this point I believe that the best choices are: > > >> - log4j2: the most used in the ZK ecosystem > > >> - logback: very used, simpler > > >> - JUL: always available > > >> > > >> My preference goes to LogBack for the zookeeper tarball (and so the > docker > > >> images) > > >> > > >> In my experience there is no need to super advanced configurations, > like > > >> log4j2 > > >> But a framework that is too simple won't work for production (like > simple > > >> slf4j). > > >> > > >> > > > I would drop JUL from consideration. I don't know anybody who prefers > that. > > > My preference remains log4j2. I looked into the dependency tree more, > and > > > it actually isn't as bad as I remember. When I updated Apache Accumulo > to > > > log4j2 from log4j1, there wasn't much I had to add to the POMs. But, > yeah, > > > it is broken into a couple of jars, instead of the one for logback. > The big > > > advantages to me are: 1) modern, evolution of logback and log4j1, 2) > > > actively maintained and patched quickly when necessary, 3) ANSI > colorized > > > output is nice for CLI apps for readability, 4) avoids XML for > > > configuration, and 5) matches what all my other libs are doing, so I > can > > > more easily maintain centralized logging config on my classpath. > > > > > > I'm okay with dropping consideration of slf4j-simple, but I object to > the > > > claim that it won't work for production. For a service running in > systemd, > > > I would prefer slf4j-simple, because I would use journald to manage > logs in > > > production. Currently, I use a ConsoleLogger for any such services > that use > > > log4j, and using slf4j-simple would be better over log4j than having to > > > deal with stray log4j.properties files picked up from dependency jars > on > > > the class path. > > > > > > I don't anticipate being convinced that logback is better than log4j2 > in > > > any substantial way, but I don't want to belabor the point further and > > > create more noise in these discussions. So, if the community switches > to > > > logback by default, I'll just have to swap out the runtime impl to > match my > > > cluster configs at deployment time. > > > > > > > > > > > >> > > >> > > >> Enrico > > >> > > >> > > >> > > >>> Andor > > >>> > > >>> > > >>> > > >>>> On 2022. Jan 12., at 22:47, Christopher <ctubb...@apache.org> > wrote: > > >>>> > > >>>> On Wed, Jan 12, 2022 at 10:48 AM Andor Molnar <an...@apache.org> > > >> wrote: > > >>>>> > > >>>>> slf4j-simple > > >>>>> ~~~~~~~~~~~~ > > >>>>> > > >>>>> Based on the documenation: > > >>>>> "Simple implementation of Logger that sends all enabled log > messages, > > >>> for all defined loggers, to the console (System.err).” > > >>>>> https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html > > >>>>> > > >>>>> I see the following problems with this approach and don’t know how > to > > >>> deal with them: > > >>>>> > > >>>>> 1) We won’t be able to ship log config examples for > > >>> Trace/Audit/File/RollingFile appenders as we did for log4j, because > the > > >>> simple backend doesn’t support any of them. > > >>>> > > >>>> Example Java system properties can be provided for slf4j-simple. > > >>>> Examples for other runtimes can also be provided. The ability to > > >>>> provide examples wouldn't change. To use example configs for other > > >>>> runtime implementations, they just might need to be accompanied by > > >>>> instructions on swapping out the runtime implementation on the class > > >>>> path. Personally, I think the best place for such example configs > and > > >>>> instructions is as a "how-to" reference on the website, but it could > > >>>> exist anywhere you provide documentation. > > >>>> > > >>>>> > > >>>>> 2) Refactoring the tests is problematic, because we cannot capture > log > > >>> messages in an OutputStream. However this could be circumvented by > > >>> capturing log messages on System.err probably. Need to dig more. > > >>>> > > >>>> Agreed that is problematic. I would avoid trying to capture > > >>>> System.err. Although relatively simple to do in Java, it can break > > >>>> things in surprising ways sometimes. For tests, I'd still recommend > > >>>> using some non-simple implementation for the test class path, > > >>>> regardless of what gets put in the distribution. Logback is as good > as > > >>>> any for the tests, and you've already done the work for that. > > >>>> > > >>>>> > > >>>>> 3) Lack of MDC support is a problem with this backend too. We would > > >>> have to use BasicMDCAdapter (hell knows how) which I guess requires > > >> changes > > >>> in the main codebase. > > >>>>> > > >>>>> My 2 cents still goes for logback. > > >>>>> > > >>>>> Andor > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> On 2022. Jan 12., at 16:06, Andor Molnar <an...@apache.org> > wrote: > > >>>>>> > > >>>>>> Ouch… > > >>>>>> JUL doesn’t have MDC support. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>> On 2022. Jan 12., at 12:48, Andor Molnar <an...@apache.org> > wrote: > > >>>>>>> > > >>>>>>> Thanks Chris and Christopher for resolving the licensing issue. > > >>>>>>> > > >>>>>>> Christopher, sorry for “fiasco” it might have not been accurate > to > > >>> describe what happened to log4j2 recently. Respect to Apache for > > >> responding > > >>> quickly and I understand the reason that Ted mentioned why logback > > >>> responded more reluctantly, although the problem in logback is far > less > > >>> severe. I also agree that less CVEs doesn’t mean more secure > software. At > > >>> the same time I believe less code leads to less CVEs. Maybe not > always, > > >> but > > >>> in most cases. > > >>>>>>> > > >>>>>>> All in all, I still tend to logback being better choice for > > >> ZooKeeper > > >>> than log4j2. Mentioning the dependency hell-ish situation at the end > of > > >>> your e-mail sounds like a con. > > >>>>>>> > > >>>>>>> Let’s take a quick look at the other alternatives. > > >>>>>>> > > >>>>>>> Pat just opened my eyes recently that JUL (java.util.logging) > could > > >>> actually be a logging _backend_ of SLF4j instead of facade > replacement. > > >> The > > >>> biggest pro could be that it’s already built in JDK, no need to add > > >> further > > >>> dependencies. I’m preparing a side-by-side patch for JUL migration > just > > >> to > > >>> see the differences. > > >>>>>>> > > >>>>>>> slf4j-simple could still be a viable option. I haven’t heard > enough > > >>> feedback from the community to say something for sure. (I will only > > >> prepare > > >>> another PR for that, if I see strong desire from folks here.) > > >>>>>>> > > >>>>>>> Andor > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>> On 2022. Jan 12., at 1:15, Chris Nauroth <cnaur...@apache.org> > > >>> wrote: > > >>>>>>>> > > >>>>>>>> The licensing question is resolved. We can state our choice of > EPL, > > >>> and > > >>>>>>>> include only the text of EPL. > > >>>>>>>> > > >>>>>>>> Chris Nauroth > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On Mon, Jan 10, 2022 at 1:05 PM Ted Dunning < > ted.dunn...@gmail.com > > >>> > > >>> wrote: > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I would add one more point. Logback has roughly benevolent > > >> dictator > > >>>>>>>>> governance, Log4j is Apache. During the recent kerfuffle, > Apache > > >>> responded > > >>>>>>>>> sooner because it only took one of n people to start > responding. > > >>> Logback's > > >>>>>>>>> response for quite some time was "that's an Apache problem" > even > > >>> though > > >>>>>>>>> they had very similar vulnerability through JNDI. The root > cause > > >> of > > >>> the > > >>>>>>>>> vulnerability (in my opinion) was feature-itis but the BDFL > model > > >>> caused > > >>>>>>>>> logback to lose considerable time before responding > effectively. > > >>>>>>>>> > > >>>>>>>>> My own slightly-more-than-joking preference is to find the > logging > > >>>>>>>>> framework with the fewest features and options. I seriously > doubt > > >>> if the > > >>>>>>>>> speed differences can be measured in a realistic situation and > the > > >>> risk of > > >>>>>>>>> feature creep is significant. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On Mon, Jan 10, 2022 at 6:17 AM Andor Molnar <an...@apache.org > > > > >>> wrote: > > >>>>>>>>> > > >>>>>>>>>> Thanks for all the feedback and concerns folks. I’m trying > > >>> organize them > > >>>>>>>>>> in bullet points. Order is random, not importance. > > >>>>>>>>>> > > >>>>>>>>>> 1) Licence. I’m not familiar with dual-licensing either. > Maybe we > > >>> need > > >>>>>>>>>> somebody with better Apache knowledge around this or ask the > > >> legal > > >>> team, > > >>>>>>>>>> I’m not sure. Hope this won’t be a blocker for logback. > > >>>>>>>>>> > > >>>>>>>>>> 2) Compatibility with other projects. "It has taken a long > time, > > >>> but it > > >>>>>>>>>> appears that the wider big data > > >>>>>>>>>> ecosystem is coming around to Log4J 2.” > > >>>>>>>>>> > > >>>>>>>>>> The way I see it and to be honest I'm almost always a > > >>> “go-with-the-flow” > > >>>>>>>>>> guy especially when comes to Hadoop, but the recent fiasco is > a > > >>> good > > >>>>>>>>>> example of how bad idea it could be sometimes. Thanks Lord > that > > >>> ZooKeeper > > >>>>>>>>>> still hasn’t moved to lo4j2 yet which saved me tons of working > > >>> hours in my > > >>>>>>>>>> employer. > > >>>>>>>>>> > > >>>>>>>>>> 3) Functionality of log4j2. In a nutshell: YAGNI. You don’t > need > > >> to > > >>>>>>>>>> implement or prepare for something which you don’t need _at > the > > >>> moment_. > > >>>>>>>>>> That was my main intention of moving towards logback. Simple, > > >>> fast, enough. > > >>>>>>>>>> > > >>>>>>>>>> 4) Performance. slf4j+logback outperforms basically > everything: > > >>>>>>>>>> > > >>> > > >> > https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging > > >>>>>>>>>> I haven’t verified it myself, so this might not be rock solid > > >>> advantage. > > >>>>>>>>>> Based on the article and given the amount of work needed to > > >>> replace the > > >>>>>>>>>> logging facade SLF4j with something else like j.u.l. is not > the > > >>> train I > > >>>>>>>>>> originally wanted to jump on. > > >>>>>>>>>> > > >>>>>>>>>> So, I believe the question in this topic is “which default > SLF4j > > >>> logging > > >>>>>>>>>> implementation shall ZK ship by default?” > > >>>>>>>>>> > > >>>>>>>>>> 5) Backward compatibility. That’s something I still need to > work > > >>> on. > > >>>>>>>>>> Logback config translator is pretty neat: > > >>>>>>>>>> https://logback.qos.ch/translator/ so, upgrading existing > config > > >>> files > > >>>>>>>>>> should not be a problem. Additionally we keep log4j1 still an > > >>> option as the > > >>>>>>>>>> backend. > > >>>>>>>>>> > > >>>>>>>>>> Apologies I didn’t have time to take a look at slf4j-simple > for > > >>> our tests > > >>>>>>>>>> yet, but looks like this option has already got support from > > >>> multiple folks > > >>>>>>>>>> in the community, so worth a shot. > > >>>>>>>>>> > > >>>>>>>>>> Thanks > > >>>>>>>>>> > > >>>>>>>>>> Andor > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> On 2022. Jan 7., at 21:18, Patrick Hunt <ph...@apache.org> > > >> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>> On Fri, Jan 7, 2022 at 12:10 PM Ted Dunning < > > >>> ted.dunn...@gmail.com> > > >>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> I have been watching the private and public mailing lists > for > > >>> Apache > > >>>>>>>>>>>> Logging as part of $dayjob as well. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I read the mood there differently. The most recent comment I > > >>> remember > > >>>>>>>>>> was a > > >>>>>>>>>>>> confirmation that "no bugfixes or security patches are > planned > > >>> for > > >>>>>>>>>> log4j1". > > >>>>>>>>>>>> > > >>>>>>>>>>>> Log4j2 really is much larger than necessary. This is, in my > > >>> opinion, > > >>>>>>>>>> the > > >>>>>>>>>>>> root cause of the recent farago. > > >>>>>>>>>>>> > > >>>>>>>>>>>> But having a cutaway by using slf4j is a very reasonable > > >>> position to > > >>>>>>>>>> take > > >>>>>>>>>>>> there. Customers can use log4j2 if they want to or opt for > > >>> simpler > > >>>>>>>>>> systems. > > >>>>>>>>>>>> Our default can be as simple as we like (even just > > >> util.logging). > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> That is a really good point Ted, one that came to mind a > couple > > >>> weeks > > >>>>>>>>>> ago > > >>>>>>>>>>> but I never circled back on - why are we not using > util.logging > > >> by > > >>>>>>>>>> default? > > >>>>>>>>>>> Assuming end users can configure (slf4j) whatever they want. > > >>> Perhaps we > > >>>>>>>>>>> could even ship "samples" for the various options if there is > > >>>>>>>>>> interest... > > >>>>>>>>>>> > > >>>>>>>>>>> Regards, > > >>>>>>>>>>> > > >>>>>>>>>>> Patrick > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> On Fri, Jan 7, 2022 at 9:57 AM Patrick Hunt < > ph...@apache.org> > > >>> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> ... > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I also see that there is interest (upstream/apache I mean) > in > > >>>>>>>>>>>>> resurrecting log4j1 - imo that could also be a good path > for > > >> us. > > >
