Replace log4j2 with tinylog2 + slf4j bridge

[Siedlerchr]

We always get this Logger error messages on startup and we use a snapshot version of log4j2 which will probably take a long time until it's stable.

We already use slf4j as a Logger interface, so switching to another underlying logger should not be that complicated. Most stuff should be compatible.
We currently use slf4j-2.0.0. This requires at least tinylog 2.4

https://tinylog.org/v2/download/#slf4j

What needs to be changed?

1. Replace log4j2 with tinylog and the bindings.
2. Investigate if we still need our custom Logging Plugins or if they need to be converted https://tinylog.org/v2/extending/
3. Remove log4j stuff also from jpackage/jlink
4. Test if it works on all platforms

[koppor]

Historic remark: In 2017, I replaced our hole logging by jcabi framework at #3015.

Two concerns:

1. The method signature for logging exceptions was very different ([WIP] Use jcabi-log to reduce startup time #3015 (comment))
2. No SLF4J was used.

In last devcall we discussed that we want to keep slf4j. - For me, it would be OK to even go away from slf4j for logging our things in case this increases startup time.

[koppor]

This will probably fix #5475 (refs #5475 (comment)).

[ThiloteE]

log4j seems to have a critical software issue. Germany's federal ministry for information security put it on code red:

• https://www.bsi.bund.de/EN/Home/home_node.html
• https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=8

[Siedlerchr]

JabRef uses version 3.x snapshot. Gets automatically updated. And JabRef does not really log user input and is not running on a server.

[ThiloteE]

Ah nice, this critical security issue seems to affect versions 2 .0 - 2.14 only. Not relevant for Jabref then :)

Edit: But what about Jabref 5.3? :O

We currently use slf4j-2.0.0. This requires at least tinylog 2.4

• Koppor August 2021.

This would mean that Jabref 5.4 should be dropped soon, no?

[calixtus]

We expect to be able to release 5.4 in the next few days / two weeks.
But to adress your concerns, I just checked 5.3: it's using log4j-3-snapshot too.

[navoooo]

And JabRef does not really log user input and is not running on a server.

It does not have to run on a server to be targeted, a compromised BibTeX/BibLaTeX database distributed by mail or downloaded could've been enough if JabRef was vulnerable. The file format is commonly exchanged by various means and is not generally suspected of malicious content, so if it were possible to load executable code through this with a well-placed string, it's not hard to imagine it being used as a delivery method for worms or ransomware targeting researchers.

It at least appeared to me as if there might be some candidates too, e.g. from bibfile directly, from PDF annotations and presumably user input, but I did not look into it further after finding the log4j version string.

[dengelt]

But to adress your concerns, I just checked 5.3: it's using log4j-3-snapshot too.

Does that really mean it's not vulnerable though? Isn't the "3.0.0-SNAPSHOT" version of log4j just whatever is currently on the master branch? At least I can't find any actual released versions with that version number anywhere, and nobody seems to mention it when talking about the log4shell vulnerability.

If that is the case, then anyone building JabRef before 12th December would have a vulnerable version (including the 5.3 binaries distributed on the release page that were built on 5th July).

[Siedlerchr]

No idea though, but seems possible. There might be more differences between 2.x and 3.x. However, we are preparing a release in the next days which will then include the latest available version.
Despite that, the attack surface in JabRef is extremely low. I checked if I can trigger this while importing (e.g a modified bib file et but could not trigger the vuln..

[koppor]

Just for the record:

• log4j hotpatch for running JVM instances: https://github.com/corretto/hotpatch-for-apache-log4j2
• patch for new JVM instances: https://github.com/nccgroup/log4j-jndi-be-gone

[cinderbdt]

Could you please comment on where on the Windows distribution one would replace the log4j2 or mitigate it?
Thank you.

[Siedlerchr]

You would need to put the agent into the folder runtime\bin and modify the jabref.bat start script and add it to the command line arguments before the "-m" e
For linux and mac use the JabRef shellscript starter.

pushd %DIR% & %JAVA_EXEC% %CDS_JVM_OPTS%  -p "%~dp0/../app" -javaagent:path/to/log4j-jndi-be-gone-1.0.0-standalone.jar -m org.jabref/org.jabref.gui.JabRefLauncher  %* & popd

[calixtus]

Good news, we just merged #8226 into the main branch, so in 5.4 Tinylog will be used instead of log4j.
We plan to release before christmas.