Add audit fixes #41
Add audit fixes #41
Conversation
* Ignore validator address in EmailRecoveryModule * Compile warnings & errors
There was a problem hiding this comment.
Thanks for raising this @SoraSuegami. A few additional comments:
-
Looks like a few Safe tests are failing - I haven't looked into these as part of this review as ran out of time.
-
We notified zellic of an existing bug in the pre audit questionnaire - “Bug from not checking if module is installed in configureRecovery”. They agreed this needs fixing - we just need to add a check that previously existed - dm'd you with the message link
-
Based on these discussions from audit chat:
we need a function that anyone to cancel an ongoing recovery request after some time period for the case that a hash of the invalid argument is set when a wallet owner loses a private key.
Certainly, allowing anyone to cancel an ongoing recovery request after a certain period can prevent issues with improperly set hashes. However, I don't think this is the best practice, and I believe fixing the root cause would be better for improving code quality.
I think the contracts should have a function for anyone to cancel an ongoing recovery request after a certain period.
This is because 1) canceling the request keeps liveness even if we have any missing bug that causes the recovery fail and 2) it is difficult to prevent an invalid hash in the processRecovery function since it cannot access to recoveryData for that hash.
However, I agree that we add more validations of recoveryData and its hash.
a. Should we add a expiry time from when the recovery request is started? I think that sounds reasonable
b. and/or in addition to adding an expiry time, do you have any ideas on how we could fix the root cause of this issue? E.g. is the solution some extra validation (maybe it's an optional security check that developers can chose to add, to still provide out of the box recovery), is it offchain validation, is it do nothing etc
- Do you think it is reasonable to do a rename of the contracts to account for body parsing being a feature in the upcoming months? e.g. the word
subjectis used a lot in the repo and we have contracts calledSubjectHandlers. A rename is technically out of scope for audit fixes however, this naming could be misleading in the future. Maybe at least a rename of the subject handlers would be useful? wdyt?
| * @dev In order to prevent unexpected behaviour when reinstalling account modules, the module | ||
| * should be deinitialized. This should include remove state accociated with an account. | ||
| */ | ||
| function deInitRecoveryModule(address account) internal onlyWhenNotRecovering { |
There was a problem hiding this comment.
For completeness even though risk is low, can you add unit tests for this new function?
You can just replicate EmailRecoveryManager_deInitRecoveryModule_Test, but for the new internal function with the account argument. You could even add tests in the same file.
Would need to update the harness to expose the internal function
There was a problem hiding this comment.
Thank you, I've just added deInitRecoveryModuleWithAddress.t.sol.
| ); | ||
| } | ||
|
|
||
| function test_Constructor_RevertWhen_UnsafeExecuteSelector() public { | ||
| function test_Constructor_RevertWhen_SafeNotAllowedSelector() public { |
There was a problem hiding this comment.
Nitpick:
Don't think this minor duplication matters, but fyi test_Constructor_RevertWhen_SafeNotAllowedSelector is just replicating the same logic as test_Constructor_RevertWhen_UnsafeOnInstallSelector, as the second function still gets called when the account type is Safe. Same for test_AllowValidatorRecovery_RevertWhen_SafeNotAllowedSelector in allowValidatorRecovery.t.sol
Happy to leave as is
I think we can just remove a recovery request in the
I think it is difficult to completely prevent an invalid recovery data since the
I renamed them in another branch! |
… it's duplicated.
* Fix test cases in allow validator recovery. * Add mockCall for isModuleInstalled function.
No description provided.