How do I check the version of log4j library version deployed in the Java runtime?

[pantdeepak]

As clearly indicated in the Log4j support page, please use mailing lists for questions!

Up until version 2.20.0, I was able to use following method to check the version #.
org.apache.logging.log4j.LogManager.class.getPackage().getImplementationVersion()

Starting version 2.21.1 the above method returns null as I could not find "Implementation-Version" entry in the MANIFEST.MF file.

[rgoers]

This is a bug introduced by the ne CI release process.RalphOn Oct 30, 2023, at 10:28 AM, Deepak Pant ***@***.***> wrote: As clearly indicated in the Log4j support page, please use mailing lists for questions! Up until version 2.20.0, I was able to use following method to check the version #. org.apache.logging.log4j.LogManager.class.getPackage().getImplementationVersion() Starting version 2.21.1 the above method returns null as I could not find "Implementation-Version" entry in the MANIFEST.MF file. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[vy]

@pantdeepak, thanks for the report, I am on it.

@rgoers, not by the CI release process, but the newly employed bnd-maven-plugin.

[ppkarwasz]

Generally speaking one can not expect Package#getImplementationVersion to return anything useful. This is based on an Oracle Java Product Versioning Specification, which even contains errors in it (like Package-Version instead of Implementation-Version). The Maven Archiver Plugin also does not fill these entries by default.

However, since Log4j used to provide the Specification-* and Implementation-* versions, we should probably restore them for backward compatibility.

Remark: if the purpose of this version check is a basic scan for vulnerable versions, I would rather parse the META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties resource, instead of relying on Package.

The presence of such a file is as "standard" as the Implementation-* headers (even more, since the Maven Archiver Plugin generates it by default) and the resource is usually copied in shaded artifacts.

Using this method you could find that the old pax-logging-log4j2 artifact is vulnerable to Log4Shell, while a Package.getImplementationVersion check will not discover anything.

[vy]

@pantdeepak, Log4j et al. is parented by logging-parent and I have fixed the problem there: apache/logging-parent@a43a0b2. logging-parent version 10.3.0 is expected to be released next week and promptly its version will be bumped for Log4j et al.

[pantdeepak]

Thank you very much for your prompt attention to this issue. Much appreciated.