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 wrapper execution. This PR skip balance checks where wrappers are defined, mirroring what we do for flash loans with flash loan hints.

Signature checks are skipped for all 1271 orders, but kept for presign/Eip712 as these should always be valid independent of prehooks/wrappers. We have been running this way in prod for a while and I just cleaned up the flags.

Changes

• Skip balance validation for ordres with wrappers
• 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.

[MartinquaXD]

The change looks alright to me. Regarding the issue with the attack vector:
This change is only supposed to unlock certain complicated order setups ASAP. IMO in the long term we should refactor the balance checking logic to be compatible with all the feature we offer. But this will be quite a bit more work.

[MartinquaXD]

Could you also remove this part while you are at it. Since the redesign of Aave's repayment flow this is requirement is no longer correct.

[fafk]

Changed to

            if let Some(fetched_app_data) = app_data.get(&order.app_data.hash()) {
                order.app_data = fetched_app_data.clone().into();
                if order.app_data.flashloan().is_some() {
                    return true;
                }
            }

[kaze-cow]

I haven't actually carefully reviewed the code itself. But I was able to incorporate these changes into the feat/playground-use-staging branch and verified that after adding the necessary environment variable settings to indicate Euler appcode as an exclusion, the orders are succeeding to process. Any further changes in that branch are just log changes, etc.

Thanks @fafk !

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to bypass balance checks for certain orders and removes some now-obsolete configuration flags. However, the implementation of the balance check bypass is currently unrestricted, allowing any user to bypass these checks by including a wrapper in their AppData, posing a high risk of Denial of Service (DoS). The removal of EIP-1271 signature validation in the autopilot service also reduces defense-in-depth. Additionally, a critical logic issue was found in the new caching implementation, and there's a discrepancy between the intended appCode filtering and the actual wrappers-based implementation. It is recommended to implement the restricted appCode filtering, retain signature validation, and resolve the caching logic.

[squadgazzz]

@fafk could you update the PR description? I assume it doesn't reflect the changes anymore, so it's hard to understand the reasoning behind.

[fafk]

@fafk could you update the PR description? I assume it doesn't reflect the changes anymore, so it's hard to understand the reasoning behind.

Done, thanks! I reworked the whole PR and forgot to update the desc. 🙇

[MartinquaXD]

Looks okay to me.