Don't flag the Gradle shadow plugin 7.1.2 (shadow-7.1.2.jar) as vulnerable

[Alex Landau]

The Gradle Shadow plugin is a fairly common development tool. Versions before 7.1.2 included unsafe versions of log4j, but 7.1.2 uses log4j 2.17.1.

As of 1.9.0, log4j-sniffer flags shadow-7.1.2.jar for deletion. This is because it is itself a fat jar that contains a JndiLookup class at a non-standard location (prefixed with "shadow/"). The detection can be avoided by running with --disable-flagging-jndi-lookup, but I don't know how safe that is, and I don't control the environment where this is affecting me and other users.

This is particularly annoying in that Gradle doesn't recover from the situation in which the jar is deleted from ~/.gradle/caches/jars-9/. In that situation, it assumes the jar is still present (due to a .receipt file) and puts its missing location on the classpath; the plugin then fails to get applied on subsequent runs, with Gradle never redownloading the jar.

Here's the workaround I've been suggesting for people running into this, in the meantime:

try {
    apply plugin: 'com.github.johnrengelman.shadow'
} catch (Exception e) {
    throw new GradleException("The shadow plugin failed to apply properly. There's a known issue with the log4j sniffer " +
    "that can cause this to happen; try running this as a workaround: rm ~/.gradle/caches/jars-*/*/shadow-*.jar.receipt", e);
}

[Alex Landau]

I'm getting help from the log4j-sniffer team here via internal channels. The conclusion is that in this particular case, the scanner was not using the delete command, which would have left this jar alone; instead, for historical reasons, it was using the crawl command and deleting any files that were listed. (I was unaware of this difference and only tested this jar myself using the crawl command.)

The resolution for this case is to switch to using the delete command.