Skip checks for defined appCodes

[fafk]

Description

For the integration with Euler we want to skip balance checks, because the order will get the necessary funds from pre-hooks. This PR adds a new config that allows to define appCode values (from AppData) that we skip these validations for. Signature checks are skipped for all 1271 orders, but kept for others as presign/Eip712 should always be valid independent of prehooks.

Changes

• Added a new config --filter-bypass-app-data-sources="Euler","FooApp"
• Added a new type AppCodeBypass that encapsulates the logic that decides which orders should skip balance validations
• A cache so we don't keep parsing appdata for every auction
• Nuked disable_1271_order_sig_filter and disable_1271_order_balance_filter config flags - 1271 now just always skips these checks

How to test

Unit tests.

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to bypass signature and balance checks for orders from specified applications using an appCode. However, the implementation has several security vulnerabilities: it allows regular ECDSA orders to bypass critical security checks, the appCode is user-controlled and can be spoofed, and an unbounded cache could lead to a Denial of Service. Additionally, there is a race condition in the appCode caching logic that can lead to redundant work. It is recommended to restrict the bypass to EIP-1271 orders, verify the app_data hash, and use a bounded cache.

[gemini-code-assist]

Code Review

This pull request adds a feature to bypass balance and signature checks for orders from specified appCode sources. However, the current implementation introduces significant security vulnerabilities, including an unauthenticated filter bypass where the user-provided appCode can be easily spoofed, and a potential Denial of Service due to unbounded cache growth that could lead to memory exhaustion. Additionally, the implementation in AppCodeBypass::build_bypass_set contains critical syntax errors where if let is incorrectly combined with a boolean condition using &&, which will cause compilation to fail.

[squadgazzz]

Since anyone can specify anything here, could this lead to an attack where the balance is not checked for unexpected orders? So the system could be flooded with orders with insufficient balance that only fail during settlement encoding.

[fafk]

The orderbook validates balances, so you can't do that. The issue here is that the autopilot doesn't run prehooks which make sure you have the right balance while orderbook does. In the long run we want to nuke all validations in the autopilot.

[squadgazzz]

I am not following, sorry. Are you saying this app code skips the balance validation in the autopilot, but not in the orderbook?

[fafk]

Yes that's right.

[squadgazzz]

The orderbook validates balances

I can't find it. Could you point me to this check? The only check I found is the ability of the owner to send at least 1 atom of the token:

services/crates/shared/src/order_validation.rs

Lines 406 to 424 in fe6e19a

	/// Verifies that tokens can actually be transferred from the user account
	/// to the settlement contract (takes pre-hooks into account).
	async fn ensure_token_is_transferable(
	&self,
	order: &OrderCreation,
	owner: Address,
	app_data: &OrderAppData,
	) -> Result<(), ValidationError> {
	let mut res = Ok(());
	// Simulate transferring a small token balance into the settlement contract.
	// As a spam protection we require that an account must have at least 1 atom
	// of the sell_token. However, some tokens (e.g. rebasing tokens) actually run
	// into numerical issues with such small amounts. But there are also tokens
	// where a single atom is already quite expensive (tokenized stocks).
	// To cover both cases we simulate multiple small transfers. As soon as one
	// passes we consider the token transferable. If all transfers fail we return
	// the last error.
	for transfer_amount in [1, 10, 100].into_iter().map(U256::from) {