Maker Deployer (or a different EOA) still controls CHANGE_LOG contract and could hamper current governance vote

#1

The current governance vote will execute a spell that uses CHANGE_LOG contract to fetch the vat address and all the ilks from.
Address 0xda0fab060e6cc7b1C0AA105d29Bd50D71f036711 is an EOA (and in particular is not controlled by the governance, it seems to be connected to Maker Deployer 5, maybe it is the 6th Maker Deployer address?).

This address can set a malicious value to MCD_VAT, and as a result either revert any attempt to the execution of the spell, or cause only part of the spell to get executed.
It does not seem a real damage could be done beside forcing only partial execution, but idk if e.g., raising YFI-A line without raising Line will have any side effects.

From my side, I have a smart contract (B.Protocol) who relies on CHAIN_LOG, and it would be nice if in the long term only the governance (ds-pause) would control it.

7 Likes
#2

Yes, the SC team currently retains access to a ward on this contract. This was communicated here. Since the on-chain changelog is a very new feature we kept control of this contract while we populated it and to manage any non-governance related contracts that are missing (I think we realized this weekend that the vote proxy is not in the changelog and should be added).

The Foundation currently maintains changelog.makerdao.com and it’s our goal to keep them in sync. If the community is ready to take this on exclusively we can either, (1) remove the auth using the deployer itself right now, or (2) remove the auth in an upcoming exec. Either way will have an on-chain record.

4 Likes
#3

ok, i am just saying it might have been better if the spell would fetch the values from the CHANGELOG upon deployment, and not upon execution, as it give the team the power to override the governance vote.

2 Likes
#4

This is a good point and definitely something we’ll fix going forward in all spells.

Personally, I would rather see the ward flipped off in an exec, as a symbolic “passing the torch” to governance here. I think that at this point the risks of the key getting compromised is probably higher than the odds that we’d need to conveniently make an update outside of an exec.

1 Like
#5

After discussing with the team, the changelog is integrated into our processes, and since it’s used in the executive the potential danger from misuse far outweighs the benefit. I’ve gone ahead and denied the team deployer address at:

https://etherscan.io/tx/0xb37cc644e1d592889b26f0b4b0cba0ffbc732dde8f12d1879ad42c4d124181e0

At this point, only the Pause Proxy has access to this contract on mainnet so governance is now in full control of the changelog.

10 Likes