-
Notifications
You must be signed in to change notification settings - Fork 699
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
Permissioned contract deployment #3377
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.
This PR does not check the InstantiateOrigin
when a contract instantiates another contract. Is this intended? No matter what the answer this has to be documented on the Config
knob.
Yes, this was intended, as I think it should probably be up to the contract logic to regulate other contract instantiation. |
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.
Tests are insufficient. The instantiation extrinsics are not tested. You also need to define a special implementation for EnsureOrigin
where you can change what it does dynamically. Have a look how we do that with parameter_types!
for our TestExtension
. This will allow you to change what it does for your tests while leave it as-is for the existing tests.
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
It was actually tested, the instantiation origin was configured to allow any signed origin to deploy, and there was already a Based on your suggestion, I added more tests by dynamically restricting upload and instantiation, so it is better tested now. |
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
@Szegoo seeing your PR a bit late commented here Haven't look at the code here yet, but from the description it seems that this is something that can be done already. Can you double check and tell me what you think |
This is more configurable. |
Co-authored-by: PG Herveou <pgherveou@parity.io>
The CI pipeline was cancelled due to failure one of the required jobs. |
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.
dispatch_as
requires the origin to be root, while here the upload and instantiate origin could be set to anything(e.g. a collective).
Are you sure this is true? You should be able to check the origin in the filter. Zeitgeist is not doing this but you could do that, right?
I was referring to:
Not so sure about checking the origin in the filter though. I will look into that. |
Yes this is understood. Probably should have quoted this:
Because you don't need to use |
I don't think you can the filter only give you access to the RuntimeCall |
polkadot-sdk/substrate/frame/system/src/lib.rs Lines 444 to 455 in c34ad77
This is used by the construct_runtime here polkadot-sdk/substrate/frame/support/procedural/src/construct_runtime/expand/origin.rs Lines 164 to 170 in c34ad77
|
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.
Yes you are right. The filter does not allow access to the origin.
8f8297e
Closes: paritytech#3196 --------- Co-authored-by: Alexander Theißen <alex.theissen@me.com> Co-authored-by: PG Herveou <pgherveou@parity.io>
Closes: #3196