Tags are mutable and can change unexpectedly. Referencing actions via sha1
is more secure in that regard. Dependabot helps to automatically update to
newer versions.
Normally, for currencies that have a market price feed, Bisq provents
the user from entering offers that are more than 50% away from spot.
It recently came to light via a mediation case that this fat finger
protection in Bisq has a flaw.
A certain sequence of focus operations in the enter offer screen
causes fat finger protection to turn off, and then the user is no
longer protected from making offers that are significantly out of
the market.
To reproduce the issue:
Go to BUY (or SELL) BTC for an market priced asset, e.g. ETH
Click Create New Offer
Click the up/down arrow icon to make sure the % from market price
edit box is selected at the top.
Close the dialog, this saves the selected price format.
Click Create New Offer
Enter 0.25 BTC
Tab to the next field.
Click the up/down arrow icon to make sure the fixed price edit box
is selected at the top. The price and deviation gets auto-populated
to market price and 0% deviation.
Enter a fixed price that is 10x higher than market value.
Click "Next" and the fat finger protection warning DOES NOT pop up.
This is because the deviation still shows 0%.
The method 'getoffer' should support looking up a user's open-offers, and other users' available offers.
- Adjust api-beta-test-guide.md to use only 'getoffer'.
- Adjust trade simulation scripts to use only 'getoffer'.
- Adjust api testcases to use 'getoffer' in place of 'getmyoffer'.
- Mark appropriate methods and protobuf msgs as deprecated.
Done via `./gradlew wrapper --gradle-version 7.3.3 --distribution-type all`
From the release description:
This is a patch release for Gradle 7.3.
It fixes the following issues:
* #19360 Upgrade checks to Log4j 2.17.0
We recommend users upgrade to 7.3.3 instead of 7.3.
See also https://github.com/gradle/gradle/releases/tag/v7.3.3
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.
