GitHub user ppkarwasz added a comment to the discussion: Removing `StructuredDataMessage` and all other RFC 5424 et al.
What is your definition of a structured layout? We already agreed that BSD syslog is **not** structured: it is a set of loose conventions that every implementation applies slightly differently. But I do not follow why RFC 5424 fails the bar. If the reason is that it imposes length and syntax restrictions (on `SD-ID`, `PARAM-NAME`, and friends), then XML fails by the exact same standard: element names have their own syntax restrictions, and the XML layouts had the very same gap on non-printable characters. I have no objection to removing these classes in a **major** release. What gives me pause is that this reads like a removal in `2.x`, because there is no `3.x` line for the Log4j API. That changes the calculus: 1. **Usage is poor, but not zero.** This would, for instance, break OpenTelemetry, which builds on these classes directly (see [`LogEventToReplay`](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/log4j/log4j-appender-2.17/library/src/main/java/io/opentelemetry/instrumentation/log4j/appender/v2_17/LogEventToReplay.java)). The question is not how many people call `StructuredDataMessage`, but whether breaking the ones who do is worth it in a minor release. 2. **Everything gets security reports.** The "I found Log4Shell in my garage" cluster is comparable in size to the RFC 5424 cluster and the XML cluster, and a large part of it exists only because we did not release fast enough and collected duplicates. A few highlights from the last six months: - "Apache Log4j 2.x — Infinite Recursion Leading to Denial of Service (CVE-2021-45105)": a report rediscovering CVE-2021-45105, which it cites by number, roughly four years late. - "Log4Shell primitive (JNDI lookup → outbound LDAP) with SSRF/Exfil evidence": breaking news that Log4Shell can also be pointed at internal hosts. - "Remote log4net configuration via URI leads to SSRF and remote code execution": I genuinely cannot reconstruct what this one was claiming. - "log4j-docker DockerLookup performs unvalidated SSRF via DOCKER_URI environment variable — AWS IMDSv1 credential theft confirmed": an attacker who already controls the `DOCKER_URI` environment variable confirms they can reach an endpoint. - "Log4j Configuration Processing Vulnerability Report" and "Log4j Lookup Vulnerability Report": two near-content-free filings against `Interpolator`/`StrSubstitutor`, both self-rated High. None of these are RFC 5424, and removing RFC 5424 would not have stopped a single one of them. 3. **The actual fix cost has been modest.** Over the past three months we shipped fixes for several real issues. For RFC 5424 I wrote two patches: far less code than the XML layouts needed, and certainly easier than the `verifyHostName` tests. **TL;DR:** I would recommend moderation. The real question is not the user count, it is whether the maintenance we are actually spending on these classes justifies breaking the usages that exist, in a minor release. How many problems do you realistically expect to keep finding in them? GitHub link: https://github.com/apache/logging-log4j2/discussions/4140#discussioncomment-17156494 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
