Re: `a.o.l.l.core.parser` package removal
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 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/
Re: `a.o.l.l.core.parser` package removal
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 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/
Weeks 2023/51 and 2024/1 in Log4j
Hi all, Due to the holiday season, work on Log4j has slowed down, but never stopped. In the past two weeks we had: ## Completed work * Jackson has been removed from the 3.x version of Log4j Core. The YAML configuration was moved to `log4j-config-yaml` (PR#2142 [1]), the rest rewritten with JsonReader. ## Ongoing work * We are continuing the big hunt for regressions in 3.x. We are analyzing module by module, cherry picking the forgotten changes. See Issue#2016[2] and Issue#2163[3] for details. ## Releases Christmas didn't stop us from releasing: * Log4j Kotlin version 1.4.0, * Log4j version 2.22.1. Thank you to all those that reviewed the release candidates. ## External activities * The OpenRewrite recipe that rewrites SLF4J to Log4j API has been accepted by the maintainers and will be published soon[4]. We could use it to rewrite Flume. * After a discussion started on our Github repo[5], EventMesh contributors are considering switching to Log4j API[6]. Till next week, Piotr [1] https://github.com/apache/logging-log4j2/pull/2142 [2] https://github.com/apache/logging-log4j2/issues/2016 [3] https://github.com/apache/logging-log4j2/issues/2163 [4] https://github.com/openrewrite/rewrite-logging-frameworks/pull/134 [5] https://github.com/apache/logging-log4j2/discussions/2133 [6] https://github.com/apache/eventmesh/issues/4697
Re: Weeks 2023/51 and 2024/1 in Log4j
Hi, On Sun, 7 Jan 2024 at 20:02, Piotr P. Karwasz wrote: > ## External activities * The PR on adding external references to the CycloneDX SBOM (e.g. the URLs for VDR/VEX files) has been discussed and reviewed and is ready to be merged. Piotr [1] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/421
