Yeah - for example to determine if log4j is used in a maven project one would have to run "mvn dependency:tree | grep log4j".

Which I did today for our 60 microservices.

And also for projects deployed as war files - container server libraries also have to be checked.

It's probably worth refining it to `log4j-core`. `log4j-api` or various bridges like `log4j-to-slf4j` are not affected, but will show up in nearly any spring boot app.

Just for reference here's the posting that confirms such:

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s...

Also worth noting this is not log4j 1, but log4j 2, like angular vs. angularjs. Version 2 is a backwards-incompatible rewrite with a different package structure, effectively a different product. Version 1 is unaffected by this mess.

Ed: linked as "infoworld article" in TFA.

This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft

https://github.com/anchore/grype

https://github.com/anchore/syft

Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images.

[1] https://www.infoworld.com/article/3644492/how-to-detect-the-...

Submitted to hn as: https://news.ycombinator.com/item?id=29543589 in case there's more discussion of tooling that might fit there.

Also found this link today -

https://support.lucidworks.com/hc/en-us/articles/44156492440...

I'm glad I couldn't get SOLR to work on indexing PDFs for a client project last year and I chose an alternate solution after reading it today...

I mitigated our SOLR install over the weekend. Best I could tell it wasn't logging queries by default so I couldn't get it to trigger. Adding an extra JVM arg to the opt list is a pretty standard SOLR thing to do, so I already have automated ways to update and push out configuration changes.

The Maven enforcer plug-in lets you fail the build if you'd depend on it either directly or indirectly [1]. Note this wouldn't find shaded usages.

[1] https://twitter.com/gunnarmorling/status/1469603432269062146

Could it be you already are on Java 8u121? They say it:

> protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

you better hope one of your dependencies hasn't vendored it!

The key for me is to have a solid backup/disaster recovery plan in place and to first assess what rollback would entail and to verify that backup data is not corrupted. Rollback is more of a final (nuclear) option, but I always need to verify that it is an option...

Data loss from rollback is far better than total corruption (if it ever gets to that point, God forbid).

It also depends greatly on the availability needs for a system of course, but everyone has to be reasonable over things they can't pre-conceive or control in these types of situations because there's no way anything can operate flawlessly and without failure.

1. The Titanic

2. The Hindenburg

3. The AWS-East Service Outage This Month

:\

I understand... The main point I'm addressing is whether an immediate A.O.R. will be in the line of "blowback", "compromise", and/or "fallout" with that statement.

It's fun to stay at the C.Y.A. :P

Can you parse this quote for me? I do not understand it.

It means that even if your Java project doesn't directly use log4j as a dependency, nor mention it explicitly, it will be very likely included as a transitive dependency via other libs (and even logging frameworks!) that you use.

Even if your code doesn't directly use Log4j, it's exceedingly likely that a library you use, or a library that uses does.

They didn't get my original statement because I'm a PHP dev (no compiling involved)... sigh

That being said, I do rely on containers, micro services, and other tools like Jenkins that will need eval.

Even if you don't use l4j in your project, you are likely to use something that uses it; a transient dependency.