Le 31/01/2022 à 00:47, Markus Koschany a écrit :
Thanks tony! I'm currently rebuilding all reverse-dependencies of log4j1.2. So far it looks like I was right and there is no package that actually requires one of the affected classes to build. None of the affected features are enabled by default hence why I would rather prefer the sledgehammer approach and just remove them. What doesn't exist can't be exploited. At least this makes sense for stable and oldstable distributions right now.
+1
I suggest to file bugs against all those packages with severity normal and ask to migrate to log4j2. If we don't make a lot of progress within the next six months then we could consider packaging reload4j, although I would rather avoid to package (and maintain) a fork of an obsolete project.
We may also pick the reload4j changes and apply them on top of log4j1.2, that should induce less work (no extra package, no dependency change, no migration to a new API).
Emmanuel Bourg
