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. 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. 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.
