Am Sonntag, dem 30.01.2022 um 15:20 -0800 schrieb tony mancill: > > Hi Markus, > > You might take some inspiration and/or patches from the reload4j > project. > > https://reload4j.qos.ch/ > > I have been using it as drop-in replacement for the log4j 1.2.x jar for > applications at ${dayjob} without any problem. Once you decide how you > would like to address the CVE, we can discuss the possibility of > packaging reload4j for bookworm as a replacement for apache-log4j1.2.
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. I don't know much about the reload4j fork at the moment. From an application manager perspective it could make sense to replace log4j1.2 with reload4j but Debian should better move forward to log4j2 in my opinion. Ideally we could just replace log4j1.2 with log4j2 in all reverse dependencies. Some upstream projects should be really shaken up by now because of log4shell and eventually move away from log4j1.2. We still have a lot of Debian packages which depend on it though. 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. Cheers, Markus
signature.asc
Description: This is a digitally signed message part
