@cowtowncoder

Dec 19, 2021

3 min read

Jackson is not affected by log4j/logback CVEs

(because it does not use either logging framework)

TL;DNR;

Background: CVE-2021–44228

Jackson and Logging: no direct relationship

  • Due to existence of multiple logging APIs, library traditionally had to decide which one to use/support — while less of a problem these days (just use slf4j), this used to be a bigger challenge when Jackson started.
    Not using logging also removes the need for one or more external dependencies.
  • Logging framework configuration is a global concern, whereas configuration of a library like Jackson is much more localized: there may be multiple unrelated uses of Jackson by frameworks and service/application itself. It seemed difficult to come up with meaningful logging where there is no real context for execution (that is, it is hard to know how Jackson is being used and what kind of processing is “log-worthy”)
  • Almost all potential logging use cases for Jackson have been (or could be) better handled by an extension point which allows SOMETHING ELSE to handle responsibilities like logging — so Jackson in effect prefers handing over possible need for logging to however is in better position to do so.
  • Many logging use cases would, in general, be better handled by tracing, or metrics/statistics interfaces: logging systems allow printing out semi-formatted text, which for events is about the least convenient and useful way to do it. It seems much better to provide structured, contextual data, over printing out human-readable (but not very machine-processable) log lines.
  1. Jackson core does not use logging frameworks directly and there are no plans for it to do so in future.
  2. Jackson core should provide extension points to expose all pertinent information so that frameworks, applications and services may produce all log output of interest they desire.

Coda