Hi,
it is possible that our university IT service may yet choose to be
strict about this and require 2.16.0 from all services open to public,
which would be bothersome four our projects in case Jena stays with
2.15.0. I guess similar situations might exist elsewhere; but perhaps
this is not a question of days, as it was with the previous CVE, since
this is not quite as severe.
My point: I may need to be able to show Jena is using 2.16.0 to be able
to run our servers at some point.
Best,
Harri Kiiskinen
On 15.12.2021 12.23, Andy Seaborne wrote:
On 14/12/2021 20:51, Brandon Sara wrote:
Should we expect another release (like version 4.3.2) given Log4J
updating to 2.16.0 in response to this other CVE:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-45046?
Going to the link to the log4j security page, the log4j team rates it as
"moderate" and says it's denial-of-service attack, not code injection
unlike 44228.
Fuseki uses log4j in default configuration.
Fuseki uses logging via slf4j.
Fuseki does not use log4j ThreadContext.
Fuseki does not use %X, %mdc, or %MDC.
The Fuseki logging built-in and default pattern uses plain %m in the
pattern:
[%d{yyyy-MM-dd HH:mm:ss}] %-10c{1} %-5p %m%n
although the user can change the log4j2 configuration to be a
non-default configurations and also set their own logging pattern
locally. that's outside the distributed Fuseki binaries.
Personal opinion: I don't see a need for 4.3.2.
Andy
--
Tutkijatohtori / post-doctoral researcher
Viral Culture in the Early Nineteenth-Century Europe (ViCE)
Movie Making Finland: Finnish fiction films as audiovisual big data,
1907–2017 (MoMaF)
Turun yliopisto / University of Turku
