-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Simplify UUPSUpgradeable along the lines of ERC1822 #3021
Simplify UUPSUpgradeable along the lines of ERC1822 #3021
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Viewed! 🧐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved 🌎
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is mostly just pending documentation and some comments in the code.
Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
You mentioned "replacing the rollback test with a simpler security mechanism with less attack surface." but can you explain what attack vectors were possible on the old mechanism? I don't see it being discussed anywhere and it's been some time since merge happed of this branch. Or can you lead me to some discussion on your forum or some docs that explains that in more details? Quite frankly, the explanation wasn't sufficient enough and didn't help me to decide which version should I use. I will stick with the old way as it seems more robust against potentially leaving out the upgrade functionality in the implementation and I don't see such protection in the new version. |
@JuliusBrain Sorry for the lack of clarity. One of our past security advisories concerned UUPS upgradeability (GHSA-5vp3-v4hc-gx76). The rollback mechanism was not exactly the cause, because there was a simpler way to execute the attack, but had that simpler way not been available this mechanism would've also been an attack vector leading to the same issue. That said, by "attack surface" we do not mean concrete attack vectors. What we're referring to is the fact that complexity increases the number of things that can go wrong and eventually may become attack vectors. In this case, we came to the conclusion that this complexity was not providing enough benefit to justify the increased surface. While the idea of doing a rollback test was very attractive to us, it is not 100% effective to prevent the removal of upgradeability, which means it does not prevent a malicious actor from doing it. What remains is protection from this happening by accident, and we believe the new mechanism is good enough to do that. |
Reviewing our initial design decisions for UUPSUpgradeable and replacing the rollback test with a simpler security mechanism with less attack surface.
PR Checklist