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

2.2.1 Release #633

Merged
merged 18 commits into from
May 24, 2023
Merged

2.2.1 Release #633

merged 18 commits into from
May 24, 2023

Conversation

zajck
Copy link
Member

@zajck zajck commented May 12, 2023

Also includes the changes for upgrade 2.1.0->2.2.0

],
remove: [],
skipSelectors: {},
facetsToInit: {},
facetsToInit: {
Copy link
Contributor

Choose a reason for hiding this comment

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

If we are adding new interfaceIds here I believe migrations scripts should also be responsible for removing old facets interfaceIds from diamond-supported interfaces.

Copy link
Contributor

Choose a reason for hiding this comment

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

would be good to validate this in upgrade tests too

Copy link
Member Author

Choose a reason for hiding this comment

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

There are two things:

  1. first we have "initialized interfaces", which are stored in ps.initializedInterfaces and are used by the onlyUninitialized modifier. This value can currently be set to true only by calling initialize, that's why I added them here. If I didn't, well, I don't think anything bad could happen. It's more of a consistency thing. This value is a bit peculiar since it can only be turned to true and not back to false (currently). I'm happy to discuss if we even need this initialization pattern or if should we simply deprecate it. Since initialize should never be registered as a diamond method, I don't see a security risk there if we omit onlyUninitialized from facets in the upcoming releases.
  2. Then we also have "supported Interfaces" which are stored in ds.supportedInterfaces and are used when someone queries erc165.supportsInterface. The upgrade script already passes a list of interfaceIds to add and remove to ProtocolInitializationHandlerFacet when the diamond cut is made. So no need to do any changes to those scripts. But yeah, it might be worth adding that to generic upgrade tests, since I assume most upgrades will change at least some interfaces.

Copy link
Contributor

@anajuliabit anajuliabit May 24, 2023

Choose a reason for hiding this comment

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

IMO modifiers should be used for security reasons and if this modifier is not prevent anything bad from happening I vote for removing

Copy link
Contributor

Choose a reason for hiding this comment

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

added an issue just to not ended up loosing this discussion as I'm going to merge this PR

@zajck zajck changed the title 2.2.1 staging addresses 2.2.1 Release May 19, 2023
@zajck zajck requested review from mischat and anajuliabit May 19, 2023 14:00
Copy link
Member

@mischat mischat left a comment

Choose a reason for hiding this comment

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

I am happy with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants