log4j implications [Was: Testing tdb2.xloader]

[Andy Seaborne <an...@apache.org>]

4.3.1 will contain the fixed log4j 2.15.0. No special mitigations necessary.

Jena uses log4j2 via the slf4j adapter from Apache Logging 
(log4j-slf4j-impl). 2.15.0 should be compatible in Jena usage with 
2.14.* for Jena 4.x.

 From the download, replace log4j-(api|core|log4j-slf4j-impl) with the 
2.15.0 versions in lib/

User applications are already deciding which logging to use - log4j2 is 
an optional dependency of Jena so it isn't pulled in by a Jena 
POM/Gradle entry. The application developer adds their choice of slf4j 
provider [*]

Fuseki however shades dependencies into a combined jar.

We could say "set the system property '-Dlog4j2.formatMsgNoLookups=true' 
but it isn't always to change scripts etc for at least two reasons

(1) when teams running the production deployment are not the 
person/people producing the deployment package.

(2) Some of our users are data people, not programmer-developers. This 
exploit is live now - making the fix easy seems like a good thing.

A new release (even if 4.3.0 only lasted a day!) is a routine upgrade 
procedure.

And it's easy to say "upgrade to 4.3.1" than explain the steps needed to 
secure 4.3.0, even if we achieve 4.4.0 at the earlier point of January 
with the reworked UI using up-to-date JS dependencies.

     Andy

[*] The patch server in RDF Delta doesn't use log4j at all - it uses 
java.util.logging (JUL). Client side, Delta does use log4j.


On 12/12/2021 13:45, Marco Neumann wrote:
> Does 4.3.1 already contain the mitigation for the Log4j2 vulnerability?