eclipse-leshan
Migrate from logback to log4j2 (because of bad security policy?)
We currently use SLF4J API in our library And for our unit tests and demos we need to use a concrete implementation. Currently we are using logback.
Logback Security Policy concerns
But we faced several time situation where logback was affected by security issue and maintainer refuse to back-port small and simple fix to old branches... :
- https://github.com/qos-ch/logback/issues/899
- https://github.com/qos-ch/logback/issues/974
I have concern with that kind of policy which consist by forcing users to :
- either upgrade to more recent version of logback (and so force to increase the minimal java requirement)
- or fix that on their own and so maintain their own custom version of logback...
- or pay for a news release ...
Bad feeling about maintainer
Deleting comments
It's up to maintainer to decide their security policy but in practise this doesn't really fit our needs.
I try to explain that with a comment on an issue and maintainer decide to delete my comment... 🤦
Refuse(not encourage) contribution Another point, some users propose to help to back-port vulnerability fix and he refused because of "lack of time"
It does not seem to be in the best interests of the community...
Migrate to log4j2 ?
So is there a good alternative ? It seems that log4j2 is a really mature project.
- ✔️ It seems to have a better Security Policy.
- ✔️ This is a community project (several contributors) where logback is a one man project.
- ✔️ log4j2 seems to be more conservative regarding minimal java version requirement (8 for log4j2 vs 11 for logback)
- ✔️ It seems that performance is now better for log4j2.
- ❌ the only drawback the jar size around 2Mo for log4j2 against ~1Mo for logback.
So I think we should consider to migrate ...
If we care about the jar size, another option would be to use slf4j-simple and configure it: https://github.com/qos-ch/slf4j/blob/master/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLoggerConfiguration.java It's quite crude but lighter. I think it would make debugging more difficult (switch log level to DEBUG by namespace would not be possible, only global)
another option would be to use the logging framework in the JRE: https://docs.oracle.com/en/java/javase/21/core/java-logging-overview.html
If we care about the jar size
This is just for demo so not sure, this is an issue to make it 1Mo heavier..
About slf4j-simple, we used it by the past. AFAIK but there was no support of color 🌈 ... which is great for demo 🙂.
About logging framework (aka JUL), we can eventually consider it but I think we should keep the SLF4J facade (to no rewrite the code and because Californium uses that facade too). I understand that this is doable with slf4j-jdk14 (java-8 as minimal version) but this is also maintained by ... and not so sure but I vaguely remember that configuring JUL was not so user friendly ? same on your side ?
JUL config file is either:
$JAVA_HOME/conf/logging.properties
which is global or you need to specify your config file using the java CLI:
java -Djava.util.logging.config.file=/path/to/your/logging.properties YourApp
Some hours after deleted my comment, logback maintainer edited his response about a back-port :
... 🤷 ...
The new version is actually released...
https://repo1.maven.org/maven2/ch/qos/logback/logback-core/1.3.16/ https://github.com/qos-ch/logback/releases/tag/v_1.3.16 https://github.com/qos-ch/logback/commits/v_1.3.16/
Hey thx a lot @HTHOU for letting know that ! I really appreciate it 🙏 !
Good news that finally that security fix was back-ported.
I made the change to integrate that new release (72e2eac). For now CVE information was not updated, so dependency management tools will still complain. (I will wait some days before to ignore warning)
Maybe my comments was not kindly enough 🤷 but with what happened I am still a bit reluctant to contonue to use logback, so I think migrate to something else still make sense 🤔. Anyway there is no urgency for now anymore.
Maybe not really "up-to-date", but in 2023 an e-mail request about CVE-2023-6378 CVE-2023-6481 and java 8 support resulted in a fast release of that fix for java 8.
Anyway, FMPOV, any (still) java 8 user must be very careful. Not only, that back-porting a fix may be denied, also missing some new functions may come with pain and may result in non-compliance with current security advice. So at least it must be recommended to test to use also newer java versions, not that it will be too late once a day.
