fix:remediations chainlight 001, 002, 004

[livingrockrises]

No description provided.

[filmakarov]

Just out of curiosity, any specific reason to do that?

[livingrockrises]

just for readability
PAYMASTER_DATA_OFFSET is always fixed.
PAYMASTER_ID_OFFSET depends on design how our paymasterandData is structured.

[livingrockrises]

can we also check CI build issue in this PR itself.
I also don't think we can tackle coverage at this point because this repo only has foundry and we must use viIR.

[filmakarov]

can we also check CI build issue in this PR itself.

The build issue for me was resolved with downgrading yarn to 1.2.xx

I also don't think we can tackle coverage at this point because this repo only has foundry and we must use viIR.

why do we must use via-IR?

[filmakarov]

can we also check CI build issue in this PR itself.

The build issue for me was resolved with downgrading yarn to 1.2.xx

I also don't think we can tackle coverage at this point because this repo only has foundry and we must use viIR.

why do we must use via-IR?

[livingrockrises]

isValidSignatureNow

check getHash. stack too deep.

[filmakarov]

check getHash. stack too deep.

getHash can be fixed.

userOp.nonce,
                keccak256(userOp.initCode),
                keccak256(userOp.callData),
                userOp.accountGasLimits,
             uint256(bytes32(userOp.paymasterAndData[PAYMASTER_VALIDATION_GAS_OFFSET:PAYMASTER_DATA_OFFSET])),
                userOp.preVerificationGas,
                userOp.gasFees,

this can be packed in one bytes

however, there are further stack too deep errors in the token paymaster

So, the best way to handle is would be this

forge coverage --ir-minimum => here

[livingrockrises]

check getHash. stack too deep.

getHash can be fixed.

userOp.nonce,
                keccak256(userOp.initCode),
                keccak256(userOp.callData),
                userOp.accountGasLimits,
             uint256(bytes32(userOp.paymasterAndData[PAYMASTER_VALIDATION_GAS_OFFSET:PAYMASTER_DATA_OFFSET])),
                userOp.preVerificationGas,
                userOp.gasFees,

this can be packed in one bytes

however, there are further stack too deep errors in the token paymaster

So, the best way to handle is would be this

forge coverage --ir-minimum => here

will use --ir-minimum then.
however we can change getHash code if we want.

[livingrockrises]

check getHash. stack too deep.

getHash can be fixed.

userOp.nonce,
                keccak256(userOp.initCode),
                keccak256(userOp.callData),
                userOp.accountGasLimits,
             uint256(bytes32(userOp.paymasterAndData[PAYMASTER_VALIDATION_GAS_OFFSET:PAYMASTER_DATA_OFFSET])),
                userOp.preVerificationGas,
                userOp.gasFees,

this can be packed in one bytes
however, there are further stack too deep errors in the token paymaster
So, the best way to handle is would be this
forge coverage --ir-minimum => here

will use --ir-minimum then. however we can change getHash code if we want.

I will fix this in another PR to revamp test cases.

[livingrockrises]

closing in favour of #24