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
