Release 4.5.2 to address CVE-2021-44228

[iloveeclipse]

We should release 4.5.2 version to quickly address CVE-2021-44228.
The PR #1865 is prerequisite.

Note: there is no known exploit using spotbugs possible yet, but since we ship and use log4j in affected version, and there are web services that run spotbugs as a part of the build pipeline, an attacker could manage to craft a pull request that contains the Java code that would somehow manage the bad pattern be part of the message logged by spotbugs.

[iloveeclipse]

@KengoTODA : the build fails with this error below: any idea?
https://github.com/spotbugs/spotbugs/runs/4510617850?check_suite_focus=true

> Task :closeSonatypeStagingRepository FAILED
FAILURE: Build failed with an exception.


Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
* What went wrong:

Execution failed for task ':closeSonatypeStagingRepository'.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
> Staging repository is still transitioning after defined time. Consider its increment. StagingRepository(id=comgithubspotbugs-1253, state=open, transitioning=true)

[KengoTODA]

Staging repository is still transitioning after defined time. Consider its increment. StagingRepository(id=comgithubspotbugs-1253, state=open, transitioning=true)

It seems that the Sonatype Nexus (oss.sonatype.org) took a long time to handle our request. The deployment itself has been succeeded.
I will check the diff, and release pushed artifact if found no problem.

[iloveeclipse]

Please approve and merge #1871 first

[KengoTODA]

It seems that Apache Foundation released 2.16.0, I'll check its release note.

https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0

[iloveeclipse]

see https://lists.apache.org/thread/6g0ls1cc9htn52hr0kkbo7dds5ts3rb5

[iloveeclipse]

I assume we could pick this release too.

[KengoTODA]

checked, thanks. Is it better to release our 4.5.2 with 2.16.0? It is possible for now.

[iloveeclipse]

Please update.

[iloveeclipse]

@KengoTODA : I think we should release maven and gradle plugins ASAP too, once core is released. WDYT? Would you push that?

[KengoTODA]

log4j is packaged only into the zip/tarball distribution, so Maven/Gradle plugins are not affected by this vulnerability.

You can see that runtime dependency of 4.5.1 release does not have log4j2 at:
https://mvnrepository.com/artifact/com.github.spotbugs/spotbugs/4.5.1

[KengoTODA]

refer to #790

[iloveeclipse]

I'm not sure if the data on maven repository is correct.
SpotBugs uses slf4j, and that one requires some binding. Once the log4j binding is used, the runtime is affected.

But you probably mean, there is nothing in spotbugs maven/gradle modules configuration or dependencies, that allows us to disallow use of unsafe log4j version.
If that is the case, we are fine.

There is no way to say slf4j to require some specific version of Log4j?

I read this on gradle:

We strongly recommended that you configure your Gradle build to reject any vulnerable version of Log4j using a dependency constraint.

• https://blog.gradle.org/log4j-vulnerability
• https://docs.gradle.org/current/userguide/rich_versions.html#rich-version-constraints

[KengoTODA]

I mean, SpotBugs core depends on slf4j-api only. Who depends on SpotBugs core needs to prepare the binding by their own.
For instance, Maven plugin uses slf4j-simple. Gradle plugin also uses slf4j-simple.

There is no way to say slf4j to require some specific version of Log4j?

There is no way. slf4j-api has no dependency on log4j's API and bindings.

[clh15683]

The released version contains both 2.15.0 and 2.16.0 jars for log4j. By classpath order log4jcore-2.15 and log4j-api 2.16 are used. While this fixes the CVE, ist should be fixed to reduce the jar size and use consistent versions.

[iloveeclipse]

@clh15683 : good find!
In fact, https://github.com/spotbugs/spotbugs/releases/download/4.5.2/eclipsePlugin.zip contains both libraries, the spotbugs packages itself aren't affected.

@KengoTODA : this happens if one builds incrementally - gradle build seem not to properly cleanup previous data. Not sure how you build the package, but ideally one should run git clean -fdx to make sure the working tree is clean.

[KengoTODA]

The release build does not use cache, so ./gradlew clean is needless and the build directory is always empty at the beginning.

https://github.com/spotbugs/spotbugs/blob/4.5.2/.github/workflows/release.yml

We use dependency cache in actions/setup-java but it caches dependencies only so it won't be affected.

I'll check the build process itself. The eclipse plugin probably have two or more dependencies on log4j, then dependency constraints could be help.

[KengoTODA]

It seems that the :spotbugs:copyLibsForEclipse task and :eclipsePlugin:copyLibsForEclipse task copy these libraries. You can confirm it by git clean -fdx && ./gradlew copyLibsForEclipse.

@iloveeclipse Do we need to include logging framework's API and bindings? More specifically, they are jar files as follows:

• log4j-api-2.15.0.jar
• log4j-api-2.16.0.jar
• log4j-core-2.15.0.jar
• log4j-core-2.16.0.jar
• log4j-slf4j18-impl-2.15.0.jar
• log4j-slf4j18-impl-2.16.0.jar
• slf4j-api-1.8.0-beta4.jar

I expect that Eclipse itself will provide API and binding in runtime. If so, we can simply exclude these libraries from the target of the copyLibsForEclipse task.

[KengoTODA]

BTW a permanent solution is removing this task, and it means that we need to resolve dependencies from Maven Central. It's technically possible but I have one blocker, so I posted to Eclipse Community Forum to ask a question at this October.

If there is no answer in that forum, I will find another way to download and extract org.eclipse.pde.build.

[iloveeclipse]

Not sure why there are so many versions? The "copy" tasks only copy declared dependencies.
I assume only one version for each library should be available at all?
Where are all the older versions coming from?

I think slf4j-api-1.8.0-beta4.jar is required, but not sure regarding log4j, I have to debug. In any case, everything that is not required to be in the plugin, must be declared as dependency in manifest.

[KengoTODA]

Not sure why there are so many versions? The "copy" tasks only copy declared dependencies.
I assume only one version for each library should be available at all?
Where are all the older versions coming from?

I believe the direct reason is that this task need to copy dependencies in testRuntimeClasspath, to support Eclipse runs unit test. So it copies not only log API but also log binding defined at:

spotbugs/spotbugs/build.gradle

Line 99 in 49fc6f6

testImplementation 'org.apache.logging.log4j:log4j-slf4j18-impl:2.15.0'

I will update this line, and regenerate manifest files for the Eclipse plugin.

[cypher256]

Log4j 2.16 CVSS 7.5 : Fixed in Log4j 2.17
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105

[iloveeclipse]

@cypher256 : thanks. I've created #1882

[KengoTODA]

SpotBugs 4.5.3 has been released, which depends on log4j 2.17.1.