About the Log4j2 vulnerabilities
After the recent weave of remote code execution vulnerabilities related to Apache Log4j we checked all the Okapi code, and that of all Okapi-related projects hosted under https://bitbucket.org/okapiframework/:
- okapi-integration-tests (DEPRECATED!)
- xliff-toolkit (DEPRECATED!)
None of that code depends on
log4j, directly or indirectly.
So we are not affected.
But it does not mean you are safe and have nothing to do.
If a product using Okapi binds
log4j with SLF4J, then they are at risk, but it is not because of Okapi.
They should apply the log4j updates as necessary, or switch to another logging framework.
The Okapi Framework uses SLF4J for logging.
That is an abstraction for various logging frameworks (e.g.
allowing developers (or even end users) to plug in the desired logging framework at deployment time.
Okapi itself does not require an update, as it does not come "out of the box" with any one logging framework.
Some of our projects use Okapi to build applications that bind to a logging framework:
- The Okapi binaries bind
- Acorn binds with
log4j12, which is not affected by the recent disclosures
log4j12is unmaintained, deprecated, and has its own share of problems)