AA-466 // Prevent initcode front-running

[filmakarov]

Add front-run protected method to K1 Factory
as per https://github.com/eth-infinitism/account-abstraction/pull/514/files#diff-63e48c2a9557cb30a347e1b089b19a170f42ca42990a55ba1a226f2e58600120

It is expected that wallets use that method in the userOp.initcode if they want to protect against front-run => the whole userOp is reverted.
The original non permissioned method is available for direct (non 4337 flow) deployments

• Fix other factories
• Update eth-infinitism dependency and fix tests as soon as new EP 0.8 is released with the EP.senderCreator method available

quote from EF:

Prevent initcode front-run (AA-466)
In prior versions, the initCode from a UserOp can be extracted from a UserOp in the mempool, and executed by front-running the actual UserOp. The result is that the attacker pays for the account deployment, instead of the account owner.
Why is this a problem? Because wallets usually don’t expect a submitted UserOperation to fail, and require to re-submit (and re-sign) it.
In order to prevent such front-run, an account’s factory contract now could do
require(msg.sender == entryPoint.senderCreator());
(As can be seen in the SimpleAccountFactory)
Note: wallets are not required to use this method, but if they don’t, they are encouraged to protect their users against such a front-run.

[openzeppelin-code]

add new method to k1

Generated at commit: 14279f8589ed54e64f73022178d6005addede7a9

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	1 1 0 6 28 36

---

For more details view the full report in OpenZeppelin Code Inspector