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.
is expected as we shut down the executor immediately.
If not thrown at shutdown or exception is not a RejectedExecutionException
we log a warning and re-throw the exception (to avoid change of behaviour
of current version). The exception is likely not handled by callers and goes up to
the uncaught exception handler.
Use 'java.nio.file.FileSystem' in place of 'java.util.jar.JarFile' to
list all the resources under a given classpath (on Windows & Linux), as
that is a bit neater and potentially more efficient than scanning the
entire ZIP directory structure.
Prevent a "URI is not hierarchical" IllegalArgumentException from the
expression, 'new File(dirUrl.toURI())', which occurs on Linux & Windows
when listing the resource directory of BSQ blocks. Adapt a solution from
StackOverflow which uses two separate code paths depending on the
environment, into the new method 'FileUtil::listResourceDirectory'.
The issue is caused by the resource URL taking one of the two forms:
file:/Users/[USER]/Java/bisq/bisq/p2p/out/production/resources/BsqBlocks_BTC_MAINNET
jar:file:...p2p.jar!/BsqBlocks_BTC_MAINNET
depending on whether the system is OSX or not.
Move timeout before shutdown sequence starts and use a Timer thread instead of
UserThread to avoid that in case the UserThread gets blocked that the timeout
would not get triggered.
Reduce timeout from 20 sec. to 10 sec.
Even if the app is maximized it does not show the full text of the
action button if the text is long. Switching Bisq to German and
maximizing the window reveals the problem.
Fixes#5862
Move timeout before shutdown sequence starts and use a Timer thread instead of
UserThread to avoid that in case the UserThread gets blocked that the timeout
would not get triggered.
Reduce timeout from 20 sec. to 10 sec.
is expected as we shut down the executor immediately.
If not thrown at shutdown or exception is not a RejectedExecutionException
we log a warning and re-throw the exception (to avoid change of behaviour
of current version). The exception is likely not handled by callers and goes up to
the uncaught exception handler.
Use 'java.nio.file.FileSystem' in place of 'java.util.jar.JarFile' to
list all the resources under a given classpath (on Windows & Linux), as
that is a bit neater and potentially more efficient than scanning the
entire ZIP directory structure.
Prevent a "URI is not hierarchical" IllegalArgumentException from the
expression, 'new File(dirUrl.toURI())', which occurs on Linux & Windows
when listing the resource directory of BSQ blocks. Adapt a solution from
StackOverflow which uses two separate code paths depending on the
environment, into the new method 'FileUtil::listResourceDirectory'.
The issue is caused by the resource URL taking one of the two forms:
file:/Users/[USER]/Java/bisq/bisq/p2p/out/production/resources/BsqBlocks_BTC_MAINNET
jar:file:...p2p.jar!/BsqBlocks_BTC_MAINNET
depending on whether the system is OSX or not.
Avoid repurposing the 'ProofOfWork.payload' field for Equihash puzzle
solutions, as that may be of later use in interactive PoW schemes such
as P2P network DoS protection (where the challenge may be a random nonce
instead of derived from the offer ID). Instead, make the payload the
UTF-8 bytes of the offer ID, just as with Hashcash.
Also, make the puzzle seed the SHA-256 hash of the payload concatenated
with the challenge, instead of just the 256-bit challenge on its own, so
that the PoW is tied to a particular payload and cannot be reused for
other payloads in the case of future randomly chosen challenges.
