setGovernor should be two step process

[code423n4]

Handle

defsec

Vulnerability details

Impact

The current governor transfer process involves the current owner calling Zap. setGovernance(). This function checks the new owner is not the zero address and proceeds to write the new owner's address into the owner's state variable. If the nominated EOA account is not a valid account, it is entirely possible the owner may accidentally transfer ownership to an uncontrolled account, breaking all functions with the onlyGovernor() modifier. Lack of two-step procedure for critical operations leaves them error-prone if the address is incorrect, the new address will take on the functionality of the new role immediately

for Ex : -Alice deploys a new version of the whitehack group address. When she invokes the whitehack group address setter to replace the address, she accidentally enters the wrong address. The new address now has access to the role immediately and is too late to revert

1. Navigate to "https://github.com/Badger-Finance/ibbtc/blob/d8b95e8d145eb196ba20033267a9ba43a17be02c/contracts/Zap.sol#L322".

Tools Used

None

Recommended Mitigation Steps

Consider implementing a two step process where the owner nominates an account and the nominated account needs to call an acceptOwnership() function for the transfer of ownership to fully succeed. This ensures the nominated EOA account is a valid and active account.

[GalloDaSballo]

Agree with the finding, although no risk here

[GalloDaSballo]

Also, it's ok to be able to send governance to an invalid address (address(0)) as that's the act of burning the keys (which is a feature, not a bug)

[0xleastwood]

as there is no risk, marking this as non-critical and duplicate of #56