Several repos are to be extracted from the main bisq repo, and their
distribution versions need to match the bisq desktop's version.
This change moves the desktop version property definition to a file
that can be read from Gradle builds having the bisq git submodule dependency,
i.e., version = file("bisq/desktop/src/main/resources/version.txt").text.trim()
Based on `master`.
This change upgrades log4j to patch fixes for recently documented
CVE-2021-45046 CVE-2021-45105 vulnerabilities related to the Log4Shell
exploit.
Like the earlier fix, Bisq does not appear to be vulnerable to these
exploits because it does not use log4j directly, only transitively
depends on it. Nevertheless, the upgrade is still the safe bet.
This commit upgrades our transitive dependency on Log4J 2 from 2.14.1 to
the newly-released 2.15.0 to avoid the CVE described at
https://www.lunasec.io/docs/blog/log4j-zero-day/.
We do not use log4j directly anywhere in our codebase, so our exposure
to this exploit was already mitigated if not eliminated, but Spring Boot
depends on Log4J 2 internally. This commit upgrades Spring Boot's
underlying dependency on Log4J to 2.15.0 in the manner recommended at
https://github.com/spring-projects/spring-boot/issues/28958.
This is in preparation for addressing log4j 2 zero day exploit described
at https://www.lunasec.io/docs/blog/log4j-zero-day/. See full details
in the next commit.
Bringing in the dependency-management plugin results in many changes to
our Gradle verification metadata file, but all are BOM / POM / Module
manifests. No additional jar or code dependencies have been whitelisted
with this change.
This commit upgrades our transitive dependency on Log4J 2 from 2.14.1 to
the newly-released 2.15.0 to avoid the CVE described at
https://www.lunasec.io/docs/blog/log4j-zero-day/.
We do not use log4j directly anywhere in our codebase, so our exposure
to this exploit was already mitigated if not eliminated, but Spring Boot
depends on Log4J 2 internally. This commit upgrades Spring Boot's
underlying dependency on Log4J to 2.15.0 in the manner recommended at
https://github.com/spring-projects/spring-boot/issues/28958.
This is in preparation for addressing log4j 2 zero day exploit described
at https://www.lunasec.io/docs/blog/log4j-zero-day/. See full details
in the next commit.
Bringing in the dependency-management plugin results in many changes to
our Gradle verification metadata file, but all are BOM / POM / Module
manifests. No additional jar or code dependencies have been whitelisted
with this change.
This change sets java source and class generation version targets to 11.
The Bisq distribution is built with JDK 11, but source target has remained at 1.10.
Upgrading allows devs to use some Java syntax features available @since 11, and it
might help anyone building the src avoid confusion over which JDK they should use
(minimum is JDK 11).
See https://docs.gradle.org/current/userguide/java_plugin.html#sec:java-extension
Problem: a
NoSuchMethodError: 'java.util.stream.Collector
com.google.common.collect.ImmutableMultiset.toImmutableMultiset()'
exception was being thrown when testing the previously-merged upgrade to
Gradle 7.3, as described at keybase://chat/bisq#testing/2466.
Solution: This problem is similar to the issue reported at
jeremylong/DependencyCheck#3221. The source of the problem was multiple
conflicting guava jars on the runtime classpath. This commit upgrades to
guava 30.1.1-jre which ensures a single jar on the classpath.
Problem: a
NoSuchMethodError: 'java.util.stream.Collector
com.google.common.collect.ImmutableMultiset.toImmutableMultiset()'
exception was being thrown when testing the previously-merged upgrade to
Gradle 7.3, as described at keybase://chat/bisq#testing/2466.
Solution: This problem is similar to the issue reported at
jeremylong/DependencyCheck#3221. The source of the problem was multiple
conflicting guava jars on the runtime classpath. This commit upgrades to
guava 30.1.1-jre which ensures a single jar on the classpath.
