Grouping of fixes for 7.3.2 #19304
Grouping of fixes for 7.3.2 #19304
Conversation
No need for a logger implementation for compilation. Issue #19300
This makes sure a log4j vulnerable version is not available for Zinc compilation even though it is actually not used by default. Issue #19300
This constraint makes sure that no vulnerable log4j-core version is made available on buildscript classpath directly or through plugin dependencies. Fixes #19300
|
OK, I've already triggered a build for you. |
|
Pre-tested commit build failed. |
|
@bot-gradle test and merge |
|
OK, I've already triggered a build for you. |
| classpathConfiguration.getDependencyConstraints().add(dependencyHandler.getConstraints().create(Log4jBannedVersion.LOG4J2_CORE_COORDINATES, constraint -> constraint.version(version -> { | ||
| version.strictly(Log4jBannedVersion.LOG4J2_CORE_STRICT_VERSION_RANGE); | ||
| version.prefer(Log4jBannedVersion.LOG4J2_CORE_PREFERRED_VERSION); | ||
| }))); |
There was a problem hiding this comment.
Might it be worth forcing an upgrade on API as well? Under this system, you get the following dependencies if strictly was used on API (one of my projects had this):
runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.apache.logging.log4j:log4j-api:{strictly 2.14.1} -> 2.14.1
+--- org.apache.logging.log4j:log4j-core:2.14.1 -> 2.15.0
| \--- org.apache.logging.log4j:log4j-api:2.15.0 -> 2.14.1
\--- org.apache.logging.log4j:log4j-core:{strictly [2.15, 3[; prefer 2.15.0} -> 2.15.0 (c)
IMO this resolution is already a little weird because it allowed 2.15.0 to be downgraded to 2.14.1, which to my understanding should not occur under a require; but ignoring that: this causes runtime errors. Including this as a default constraint might be surprising for those using strictly on their log4j-api dependency, as it will only fail at runtime!
There was a problem hiding this comment.
Thanks for sharing, and yes a first level strictly will downgrade a second level require, that is the whole point of the feature.
I wonder if we should bother. Unfortunately, because Log4j does not publish Gradle Module Metadata, it does not benefit from alignment. Though even if it did, this would cause the two strictly to conflict and you would have to add something to the build script.
Note that we are revising the way this constraint is expressed to be in the shape of an reject which is more correct in the long term.
|
Also see the follow up #19311. |
Replaces #19297, #19299 and #19301