reload4j project
Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the reload4j project is a fork of Apache log4j version 1.2.17 with the goal of fixing pressing security issues. Reload4j is a binary compatible, drop-in replacement for log4j version 1.2.17. By drop-in, we mean that you can replace log4j.jar with reload4j.jar in your build with no source code changes, no recompilation, nor rebuild being necessary.
The reload4j project offers a clear and easy migration path for the thousands of users who have an urgent need to fix vulnerabilities in log4j 1.2.17.
Please note that neither log4j 1.x nor reload4j offer a message lookup mechanism. It follows that they do not and did not suffer from the infamous log4shell vulnerability.
Goals
As mentioned above, the reload4j project aims to fix the most urgent issues in log4j 1.2.17. This is accomplished by the following steps:
- Standardize and sanitize the build - fixed in 1.2.18.0
- CVE-2021-4104 (JMSAppender) - fixed in 1.2.18.0 by hardening
- CVE-2022-23302 (JMSSink) - fixed in 1.2.18.1 by hardening
- CVE-2019-17571 (SocketServer) - fixed in 1.2.18.0 by hardening
- CVE-2020-9493 and CVE-2022-23307 (Chainsaw) - fixed in 1.2.18.1 by hardening
- CVE-2022-23305 (JDBCAppender) - fixed in 1.2.18.2 by hardening the component.
- broken MDC in newer JDKs - fixed in 1.2.18.0
- XML entity injection attack - fixed in 1.2.18.3 by hardening
- CVE-2020-9488 (SMTPAppender) fixed in 1.2.18.3 by hardening
- Fixed newly discovered XXE vulnerability against chainsaw fixed in 1.2.22 by hardening
- CVE-2023-26464 was deemed not a serious or practical menace as its attack surface is very small.
Please refer to the news page for more details.
Latest release 1.2.25
Version 1.2.25 was released on 2023-03-22. It can be found in Maven central under the following coordinates:
ch.qos.reload4j:reload4j:1.2.25
Note that reload4j releases are reproducible. Anyone can check out the tagged version from github and build it. The result should be bit-wise identical to the published version on Maven central.
Reload4j was built using Java 8 but targets Java 1.5.
The unit tests were updated but no actual code was changed except
for the removal of NTEventAppender
and the correction
of the aforementioned issues, including the CVEs.
As of version 1.7.35, the SLF4J project supports reload4j via its slf4j-reload4j module. Moreover, the "slf4j-log4j12" artifact contains a Maven relocation directive for "slf4j-reload4j".
Project roadmap
We do not expect to add new features to reload4j. However, it will see maintenance releases for the foreseeable future.
- Watch for future vulnerabilities, however unlikely
- Performance improvements, in particular fixing syncronization issues which mostly have the same single known and correctable origin
- Correct other serious bugs
- Further hardening if and when deemed necessary
Source code repository
Source code is available on github under the qos-ch/reload4j repository which was forked from apache/logging-log4j1.
Keys
All reload4j artifacts published on Maven central are signed. For each artifact, there is an associated signature file with the .asc suffix.
To verify the signature use this public key. Here is its fingerprint:
pub 2048R/A511E325 2012-04-26 Key fingerprint = 475F 3B8E 59E6 E63A A780 6748 2C7B 12F2 A511 E325 uid Ceki Gulcu <ceki@qos.ch>
See also SECURITY.md
Building
Reload4j builds with Maven and targets Java 1.5. You need to launch Maven under Java 8 or alternatively configure Maven Toolchains for Java 8.
A sample toolchains configuration can be found in .github/workflows/toolchains.xml.
Reproducible builds
Reload4j artifacts are binary reproducible, as independently attested by reproducible-central.
Bug reporting using Github issues page
You can browse issues at our github issues page. All steps undertaken in the project are first published/discussed on the reload4j mailing list or on the aforementoined issues page.
Mailing list
Name | Traffic | Subscribe | Unsubscribe | Archives |
---|---|---|---|---|
reload4j mailing list | Low | Subscribe | Unsubscribe | qos.ch |
Why not revive log4j 1.x within the Apache Software Foundation?
The reload4j project aims to fix the most urgent issues in log4j 1.2.17 which hasn't seen a new release since 2012. Note that on 2022-01-06 the Apache Logging PMC formally voted to reaffirm the EOL (End of Life) status of log4j 1.x. Despite our best efforts, it was quite impossible to revive the log4j 1.x project within the Apache Software Foundation.
Donations and sponsorship
You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions.