Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

check that target master copy has code #90

Merged
merged 18 commits into from
Dec 8, 2022

Conversation

auryn-macmillan
Copy link
Member

This PR adds a check to our proxy factory to ensure that the target mastercopy has code deployed before deploying a proxy.

cristovaoth
cristovaoth previously approved these changes Nov 30, 2022
Copy link
Contributor

@cristovaoth cristovaoth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

@nginnever
Copy link
Contributor

lgtm!

nginnever
nginnever previously approved these changes Dec 1, 2022
@auryn-macmillan
Copy link
Member Author

@nginnever, do you think this change invalidates the audit?
Given that it just adds an error, I tend to think it's fine.

It will obviously change the address of the factory though.
That being the case, any other changes that we might want to make while we're at it?

@cristovaoth
Copy link
Contributor

@nginnever, do you think this change invalidates the audit? Given that it just adds an error, I tend to think it's fine.

It's trivial to see that the change introduces no vulnerability, therefore it's fine.

However it would be nevertheless nice to have the audit reflect latest sol state.

@nginnever
Copy link
Contributor

nginnever commented Dec 4, 2022

@auryn-macmillan well this opcode has a lot of controversy around it, but I don't think there is a risk with this use case. The only risk I have seen with extcodesize would be if you are using this feature to check if a contract or EOA is making a call. The constructor returning 0 has always made that assumption a risk and with aa it will only get harder.

But this is just a security feature to help ensure that an incorrect address isn't provided. Maybe the EVM stops supporting this opcode one day, but I haven't seen any discussion around removing extcodesize and eth core is careful about not breaking contracts when they do remove anything.

@auryn-macmillan
Copy link
Member Author

Yeah, I'd be surprised if they made a breaking change with this opcode.

Nevertheless, do you see any other ways to accomplish this same kind of check in this context?
Essentially, we just want to avoid a scenario where people create a proxy that points to an address that currently has no code deployed but could later have code deployed to it.

@nginnever
Copy link
Contributor

I've tried thinking about other approaches (could always use codehash but thats the same)... but I think this still the best option. The hard part is enforcing that "there is no code", but enforcing that "there is code" shouldn't be a problem.

@auryn-macmillan
Copy link
Member Author

Before merging this, I guess we should generate a new vanity address for it.

@auryn-macmillan
Copy link
Member Author

Alrighty, I went ahead and found a new vanity address for the factory. It has 12 leading zeros! 🎉

@nginnever and @cristovaoth, could you please review the deployed code and confirm that it corresponds to the changes in this PR before we merge?

https://goerli.etherscan.io/address/0x000000000000aDdB49795b0f9bA5BC298cDda236#code

@auryn-macmillan auryn-macmillan merged commit 5f2885c into master Dec 8, 2022
@auryn-macmillan auryn-macmillan deleted the check-target-has-code branch December 8, 2022 18:03
@github-actions github-actions bot locked and limited conversation to collaborators Dec 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants