Hi, I think our example log4j2 file should be as idiomatic as possible. If YAML is now the recommended format, then it makes sense to adopt it. I would also do this directly in 4.0.0.
Like David, one concern when adding extra dependencies is CVEs. YAML is a widely used format and the libraries are actively maintained so I think it's acceptable. In my opinion, the configuration format for Kafka is a completely orthogonal issue. If people want to adopt YAML this can be done in a separate discussion. I don't see issues with using YAML for configuring log4j2 and properties for Kafka. Thanks, Mickael On Thu, Oct 31, 2024 at 5:47 PM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > > Hi Viktor, > > On 31.10.2024 10:19, Viktor Somogyi-Vass wrote: > > I could see a transition for Kafka configs too to YAML. It's widely used in > > other projects as well and for Kafka too it would make sense to group them > > for instance by log, storage, networking, security etc.. It definitely > > has an advantage that we could move to a more well defined structure and > > away from these long prefixes which are very cumbersome in some places. > > Perhaps 4.0 would have been a good candidate but given that we should > > provide backward compatibility anyway, later is good too. > > To migrate the configuration from Java Properties to YAML and maintain > BC, you can use `jackson-dataformat-properties`. This definitively can > be done in a minor release. > > [1] > https://github.com/FasterXML/jackson-dataformats-text/blob/master/properties/README.md > > > 4. Data bindings and parsers are common sources of CVEs. It looks like > > Snakeyaml is no exception ( > > https://www.cvedetails.com/version-list/0/66013/1/), though it doesn't look > > much worse than Jackson. Just to point out, this will add a bit of > > dependency overhead as we keep up with security patches. > > > > It's a good point about CVEs. I haven't seen it on the dev list but were > > there any conversations about enabling dependabot version updates? With > > automatic dependabot PRs we could get fixes in as soon as it opens the PR. > > I don't know how it works in Gradle, but with Maven we don't get > Dependabot PRs for transitive dependencies such as SnakeYAML. Since the > dependency is not present in the `pom.xml`, its version can not be > updated. Dependabot might be able to create alerts in the "Security" tab > though. > > Since Log4j is a library without an executable distribution, it is not > guaranteed that a new version of Log4j will be released each time a > vulnerability in SnakeYAML is discovered and that vulnerability is > exploitable in Log4j Core. It does not make much sense to make a new > release just to upgrade a number in `pom.xml`. > > Until VEX-es can be created automatically, the only way I can think of > to help the Kafka team with CVEs in transitive dependencies is a manual > process: > > * You mark `jackson-dataformat-yaml` with a comment like "Used by Log4j > Core". > > * If a CVE is reported against that artifact or its dependencies, you > open an issue in Log4j[2], so we can advise on the exploitability of the > CVE. > > * With that information you can decide whether to release a new Kafka > version or not. > > Piotr > > [2] https://github.com/apache/logging-log4j2/issues > >
