Then users or 3rd parties can implement their own parsers if they need to.
It might be useful to have parsers for some common formats like GELF,
Logstash or RFC-5424, and that can be implemented without using Jackson
if necessary.
/Mikael
On 2024-01-07 10:38, Mikael Ståldal wrote:
What about (re)moving the classes which actually depends on Jackson
(AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser,
YamlLogEventParser), but keeping the interfaces (LogEventParser,
TextLogEventParser, ParseException) in log4j-core?
/Mikael
On 2024-01-05 11:25, Volkan Yazıcı wrote:
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/
