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

Update Instantiate Config logic #1663

Open
jhernandezb opened this issue Oct 11, 2023 · 2 comments
Open

Update Instantiate Config logic #1663

jhernandezb opened this issue Oct 11, 2023 · 2 comments

Comments

@jhernandezb
Copy link
Contributor

jhernandezb commented Oct 11, 2023

Hi,

I've been trying to update the instantiate config to move from a multisig being allowed to a multisig + DAO, to me seems counterintuitive that this is not possible when the multisig is the "creator"/admin of the code.

		"anyOf < anyOf": {
			superSet: AccessConfig{Permission: AccessTypeAnyOfAddresses, Addresses: []string{"owner"}},
			check:    AccessConfig{Permission: AccessTypeAnyOfAddresses, Addresses: []string{"other"}},
			isSubSet: true,
		},
               "anyOf(multiple) < anyOf": {
			superSet: AccessConfig{Permission: AccessTypeAnyOfAddresses, Addresses: []string{"owner"}},
			check:    AccessConfig{Permission: AccessTypeAnyOfAddresses, Addresses: []string{"owner", "other"}},
			isSubSet: true,
		},

I added a simple test and this 2 will fail, and I think is the IsSubSet logic is applying the checks correctly but not sure if this logic should be applied when the owner is the creator of the code at least not when trying to update the config.

@pinosu
Copy link
Contributor

pinosu commented Oct 12, 2023

Thanks for bringing this up.
I think it makes sense to take into consideration the case when the creator wants to update permissions and make them less restrictive: newPermissionSet > oldPermissionSet . At the moment, the way to do so is to upload the code again with the new instantiate permission or through a gov proposal . I'm not sure if there are any drawbacks if we would remove the isSubset condition from here . @alpe WDYT??

@alpe
Copy link
Contributor

alpe commented Oct 13, 2023

Good to discuss this!
On restricted chains, the superset is defined on the chain level. This gives strong guarantees that only pre defined addresses can instantiate or modify the settings. When we would support changes by one of the accepted addresses then we give the power that was unique to gov before to them.
There can be scenarios where this is no problem and may save some steps but on the other hand you are back to trusting individuals over gov processes. There is no information on chain who or what is behind an address.
I am very open to hear other arguments. Please add some more context so that we have a better picture.

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

No branches or pull requests

3 participants