The following PoC shows a way of detecting specific types of calls, focusing on probably the most critical: rely(address). Considering that if a wrong address is given throughout the execution of the spell, the whole protocol could be at risk (same as if an authorization is denied). This PoC aims to provide the process some tools to review that the spell is acting accordingly.
Considering only rely(address), there are 2 possible scenarios: either the spell needs to make one of these calls (and give authorization to an address), or the spell does not. The testing suite then incorporates 2 tests, one for each of the possible scenarios:
testFailAuthCall: will ✅ only if NO rely(address) calls were made in spell execution
testAuthCall: requires the crafter to declare all expected rely(address) calls (will ✅ if ALL of these calls are made)
Taking into account that an alien auth call could be made in the second scenario (when we expect to see a rely event), the reviewer checklist should add something like:
- [ ] check `[PASS] testFailAuthCall`
- [ ] If `[SKIP] testFailAuthCall`: check the logs bloom and verify there's not other rely event than in `testAuthCall`
In this way, adding an automated way of testing that there are no new authorizations, and a manual way of checking them when there are some, we can entrust that no new unwanted authorization is made.
Considerations:
rely(address) comes from the legacy Note library, the test should be duplicated with new Rely(address) event
the test should also be duplicated with deny(address) and Deny(address)
adds manual labour to reviewer, tho only in special ocations (when there are new auths)
Description
The following PoC shows a way of detecting specific types of calls, focusing on probably the most critical:
rely(address). Considering that if a wrong address is given throughout the execution of the spell, the whole protocol could be at risk (same as if an authorization is denied). This PoC aims to provide the process some tools to review that the spell is acting accordingly.Considering only
rely(address), there are 2 possible scenarios: either the spell needs to make one of these calls (and give authorization to an address), or the spell does not. The testing suite then incorporates 2 tests, one for each of the possible scenarios:testFailAuthCall: will ✅ only if NOrely(address)calls were made in spell executiontestAuthCall: requires the crafter to declare all expectedrely(address)calls (will ✅ if ALL of these calls are made)Taking into account that an alien auth call could be made in the second scenario (when we expect to see a rely event), the reviewer checklist should add something like:
In this way, adding an automated way of testing that there are no new authorizations, and a manual way of checking them when there are some, we can entrust that no new unwanted authorization is made.
Considerations:
rely(address)comes from the legacy Note library, the test should be duplicated with newRely(address)eventdeny(address)andDeny(address)