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. > > 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.
signature.asc
Description: PGP signature
