Mitigations for log4j vulnerability in Gradle builds #19300
Comments
big-guy
added
in:documentation
|
side note - but an interesting feature would be the ability to ensure that certain libraries/versions with vulnerabilities are not a part of the build - and if they are somehow introduced - fail the build. |
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 now uses a combination of require and reject instead of a strictly, which will allow updates beyond the 2.x line. The previous solution was effectively preventing that with no way for the user to change that. Issue #19300
This now uses a combination of require and reject instead of a strictly, which will allow updates beyond the 2.x line. The previous solution was effectively preventing that with no way for the user to change that. Issue #19300
Follows publication of https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 Issue #19300
|
Can't find a repo for the Gradle build-cache-node, so I report this here: Version 10.1, released Dec. 13th, also still ships with |
@ZakTaccardi That's already possible with dependency constraints, see https://blog.gradle.org/log4j-vulnerability and https://threadreaderapp.com/thread/1470845889166159873.html |
|
Note that Gradle 7.3.3 will be released with a bump to log4j 2.17.0 - see #19360 |
A RCE vulnerability in log4j has been found that affects certain combinations of Java and applications using log4j 2.
This is a critical vulnerability that is actively being exploited.
While Gradle itself is not directly impacted by this, we should provide some mitigations and recommendations for Gradle users.
The following has been done in Gradle:
log4j-coreto2.16.0on the zinc compiler classpath when using the scala plugin.and requires2.16.0`More information on our blog post.
The text was updated successfully, but these errors were encountered: