Thanks… That did find some additional packages hiding this scourge (about a dozen or so packages,
around 100 packages removed after the dependency chains were resolved).
Another handy one to find where it’s hiding, since it can be bundled inside other JARs:
find / -name *.jar | xargs strings -f | grep -i log4j
If you’re on fedora, it can be useful to pipe the output of that to
cut -f 1 -d : | xargs rpm -q —whatprovides
which will give you the package names responsible for the files in question.
One of the ones I discovered required quite a number of eclipse-* packages to be removed.
Of the things that were found, there wasn’t anything I cared enough about keeping, so I’m
still inclined to believe that rpm-e is the best solution to this problem at this point.
The log4j people have updated their security advisory to say that these two mitigation measures are not sufficient to protect against the recent vulnerability:
2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ only)
3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only)
The current recommended fixes are:
1. upgrade to 2.16.0 (not 2.15.0), or
2. remove the JndiLookup.class file from log4j-core-*.jar
The difficulty is that as others have pointed out, log4j (for better or (mostly) worse) tends to get incorporated
into other JARs, so merely upgrading the system package is insufficient.
Since I had to do a full search through the entire system for all JARs containing log4j routines, and I didn’t
find anything I was unwilling to give up in that search (the only thing that sort of came close was the Arduino
IDE), I simply nuked everything found in the search (and anything that depended on such things) and feel
that my system is better off for it.