Am Sonntag, dem 30.01.2022 um 16:49 -0800 schrieb tony mancill: > On Mon, Jan 31, 2022 at 01:18:49AM +0100, Emmanuel Bourg wrote: > > 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 > > Yes, I didn't mean to imply anything otherwise for stable and oldstable.
Ok, I will remove the affected classes in Stretch and prepare a point update for Buster and Bullseye which will achieve the same. > > > > 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). > > Right. My point in writing was to point out that reload4j is a direct > fork of log4j1.2. Porting to log4j2 could be quite a bit of > (unnecessary) work. For unstable and testing I have applied the changes from the reload4j project on top of our sources now. I agree that porting every dependency to log4j2 on our own is too much work but I presume there are some projects that already did the switch a while ago and their package was simply not updated in Debian. In any case as long as reload4j continues to provide security fixes log4j1.2 should be maintainable.
signature.asc
Description: This is a digitally signed message part
