I support the idea of removing the Jackson-based `LogEvent` parser. Back in the days when `JsonLayout` was the only JSON-formatted layout, it might have made sense to provide deserialization support next to serialization. With `JsonTemplateLayout`, where the JSON structure is controlled by the user, the deserialization companion is not only impossible, but also doesn't make sense anymore.
@Piotr, do you propose removing it in `2.x` or `main`? My preference would be both. On Tue, Jan 2, 2024 at 12:09 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi, > > While working on PR#2142[1] I noticed that we have an > `a.o.l.l.core.parser` package that depends on Jackson. > > Since Log4j itself never parses log events, I would propose to remove > it from `log4j-core` and optionally move it somewhere else (Chainsaw > or Flume?). > > My main concern is vulnerability exposure: > > * I would like to prevent CVEs like CVE-2019-17571[2] from being > published against `log4j-core` in the future. Dealing with CVEs that > say "code that we never use is vulnerable to..." bring a lot of > useless PR/documentation work: we'll need to explain to users how to > mitigate a vulnerability that is almost never exploitable and our > users will also have to evaluate the exploitability of the CVE in > their own applications, > * in some not so far future we'll need to publish VEX records to > comply with regulation. Every time Jackson will publish a > deserialization vulnerability, we'll need to state that we are > vulnerable. > > What do you think? > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/2142 > [2] https://www.cvedetails.com/cve/CVE-2019-17571/ >
