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?
