This message was deleted.
# community-support
s
This message was deleted.
f
Gradle itself does not use Log4j 2 and whatever project you have it should not include Gradle and thus is not subject to the vulnerability just because Gradle has Log4j 2 somewhere in its transitives references. Well, unless I understand something wrong in your description. 😉 Check out https://blog.gradle.org/log4j-vulnerability for more information.
b
Thank you for your reply! Whenever I run a gradle sync, these files are appearing on my workstation. user/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/ This means that at some point, the gradle is using the log4j 2.10, and a hacker can run the RCE on my machine at this time. When I run a gradle sync with gradle version 6.9.2 it shows the log4j non vulnerable version 2.17. Sorry for sending a picture instead of screenshot, my workstation is highly secure and can't run slack on it
Maybe I'm missing something?
f
This means that something depends on it in your project, that is why it shows up in the cache. That does not mean that it is being called, and it most certainly does not mean that someone can call it from within Gradle since the cache is not the classpath of Gradle.
You can
rm -fr ~/.gradle
and import your project from scratch to see if it shows up again. Maybe this is just a left over from some build you ran months ago. It’s generally good practice to not wipe this stuff locally for optimal build performance across projects, but if you want to be absolutely certain that Log4j 2 does not show up anywhere, this is a way to go.
b
My project is not using log4j at all, I ran a dependency report on it. This path in my workstation is the .gradle general folder, not the project related folder. Thank you for your reply
v
Just so that you have two voices: what @Fleshgrinder said
f
Gradle uses a global cache for all projects you build to speed everything up. Also, while your project might not include Log4j in its dependencies (and thus nothing shows up in the dependency report) does not mean that there are no Gradle plugins that depend on it.
v
If it lands in that cache, either your project or maybe some Gradle plugin you use uses it.
👍 1
The things Gradle itself uses are pre-shipped and not downloaded to any cache
As you are in high-secure, I guess you cannot create a build scan?
b
Thank yall for your reply! I'll double check if there is anything on my workstation that is using the log4j
v
If so you could at least use
dependencies
and
buildEnvironment
tasks to find where it comes from
b
Something I noticed, is that when I update my gradle to 6.9.2, log4j in that specific folder appears as 2.17, which is nice but affects the app stability
f
You mean that your build breaks, because Gradle cannot affect the stability of a running app, since it’s a build tool. My only response to this, which might sound harsh but is the only possible response given the “high security” + “human lives depend on it” context: Always upgrade, everything, all the time, everywhere. It’s the only way to ensure safety and security. (Check checksums, verify signatures, … also for Gradle plugins.) Not doing so in this context is, well, reckless. Again, I don’t want to be harsh, and sorry to be so frank, but this is how it is given the context. The Log4j you see might be from the Scala plugin, in case you use Scala. That’s the one explained in the Gradle blog post I shared.
🙂 1
👍 1
b
Don't worry, I totally get where you are coming from, but it isn't up to me to decide that HAHA I guess my company doesn't want to invest months worth of salary to upgrade the gradle. And, when I mean stability, I mean updating all the dependencies, layouts and anything that's involved with updating a gradle
f
Jumping from 4.1 to 6.9.2 is definitely going to be cumbersome since you jump over 2 major upgrades. I’m not surprised. 😞 The thing is that you might not even be able to update whatever pulls the vulnerable Log4j version, since it’s probably a Gradle plugin and newer versions require a newer Gradle version. What you definitely can do is to force upgrade Log4j in all places. Gradle 4.1 is long ago for me, but something like the following in your
build.gradle
should do the trick:
Copy code
buildscript {
  dependencies {
    classpath("org.apache.logging.log4j:log4j-core:2.17.2")
  }
}

configurations.all {
  project.dependencies.add(name, "org.apache.logging.log4j:log4j-core:2.17.2")
}
This basically adds Log4j core with the latest version everywhere and thus forces resolution to this version. This is brute force and most probably has unwanted side effects, but it should work. Newer Gradle versions have better APIs to do something like this, and maybe Gradle 4.1 had some of those already too, but, as I said, Gradle 4.1 is way back for me, so I don’t remember.
v
Urgh, why should he add log4j-core to everywhere even if it is not there already? At most add a constraint, or just use the recommendation from that blog entry.
Anyway strange if a Gradle plugin depends on
log4j-core
at all, that's imho a bug per-se
f
I really don’t know what kind of APIs Gradle 4.1 had to offer, as I wrote above, the example code is going to lead to unwanted side effects. Maybe you remember 4.1 better and can provide a better code snippet.
b
thank you for your replies, I had no idea how that cache folder was generated with the log4j
so, it could be a plugin issue in the project gradle files right?
f
Yes, a plugin could depend on Log4j.
v
so, it could be a plugin issue in the project gradle files right?
I already told you how to find out, you just ignored it. 😉
hey yall! I was able to get rid of this log4j in the project so easily! I can't thank yall enough for this knowledge, I had no clue
❤️
til how cache files are generated by the gradle
f
😊