Kill switch: provide emergency upgrade path #533
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #523
Follow up #518
This PR provides an entry point in the Kernel that a new way to access the
setApp
functionality, but only when the app address that is requested to be updated is disallowed in the kill-switch instance of a DAO. It also implements a new role calledAPP_MANAGER_EMERGENCY_ROLE
, obviously different than theAPP_MANAGER_ROLE
, since it is supposed to be used from a separate flow. For example, if theAPP_MANAGER_ROLE
app has been kill-switched, then theAPP_MANAGER_EMERGENCY_ROLE
app is allowed to perform an upgrade of theAPP_MANAGER_ROLE
app.We could use this new entry point from the voting app to provide all the DAOs a way to bypass the root of authority chain in case any of its components gets kill-switched. Ofc, as explained in the issue linked, there is a list of minimum components we will need whitelist to make that happen (Kernel, ACL, Kill switch, Voting app, ...). But note that with this entry point we can now make sure we don't need the full chain whitelisted.