ppkarwasz commented on issue #1923: URL: https://github.com/apache/logging-log4j2/issues/1923#issuecomment-1786818254
Generally speaking one can not expect [`Package#getImplementationVersion`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Package.html#getImplementationVersion()) to return anything useful. This is based on an Oracle [Java Product Versioning Specification](https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html), which even contains errors in it (like `Package-Version` instead of `Implementation-Version`). The [Maven Archiver Plugin](https://maven.apache.org/shared/maven-archiver/index.html#class_manifest) 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](https://maven.apache.org/shared/maven-archiver/#class_archive) 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`](https://mvnrepository.com/artifact/org.ops4j.pax.logging/pax-logging-log4j2/2.0.10) artifact is vulnerable to Log4Shell, while a `Package.getImplementationVersion` check will not discover anything. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
