hi, Mickael I'm +1 for using the log4j2 format. Otherwise, it's odd for users to see deprecation warnings about log4j.properties when using our example files.
Best, Chia-Ping Mickael Maison <mickael.mai...@gmail.com> 於 2024年11月18日 週一 下午7:33寫道： > Hi, > > The log4j2 migration PR is pretty much ready to be merged and the > first deadlines for 4.0.0 is approaching fast. > I think we should decide which format to use in our example log4j2 > files to avoid having to update the format shortly after 4.0.0. > > This point is not really covered by KIP-653: Upgrade log4j to log4j2. > Do we want another KIP and vote or is a consensus emerging? > > Thanks, > Mickael > > On Wed, Nov 6, 2024 at 10:47 AM Mickael Maison <mickael.mai...@gmail.com> > wrote: > > > > 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 > > > > > > >
