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

Validate constitutions on the server #5132

Open
eddyashton opened this issue Mar 21, 2023 · 2 comments
Open

Validate constitutions on the server #5132

eddyashton opened this issue Mar 21, 2023 · 2 comments

Comments

@eddyashton
Copy link
Member

To prevent "invalid" constitutions being submitted and locking a service, we should add some utility functions to the governance JS API to validate a constitution script. As a minimum, we should be able to spin up an isolated JS interpreter and confirm that the proposed constitution is parseable. Ideally, that should return some description of the constitution as though it was a loaded module, so that (default, sample) constitutions can check the proposed constitution still contains the expected validate, resolve, and apply functions.

@achamayou achamayou added this to the 4.x milestone May 15, 2023
@cauldnz
Copy link
Contributor

cauldnz commented May 24, 2023

There is also the potential to lock a service by misconfiguring the Javascript runtime options. If the options are configured in such a way that the JS runtime is unable to start, it will no longer be possible to execute the Constitution and therefore no longer possible to submit a new configuration to remedy the problem.

See below PoC. Suggested initial fix would be to put some bounds checks on the sample constitution's set_js_runtime_options action.

https://gist.github.com/cauldnz/f7e52b100544526f0ebc5905ed349bbe

@eddyashton
Copy link
Member Author

@cauldnz This is a good suggestion, and I'll include it in this validation work.

It's worth clarifying that, counterintuitively, we actually want to ensure it is possible for the governing consortium to break the service in various ways. This is to justify the claim that they have full control of the service. In practice, it means it should be possible to "freeze" a service in various ways - making it impossible to add or remove future nodes, to stage recoveries, or to update the constitution. Such a service would be trading off some operational safety (it can never be updated!) for a stronger guarantee to the users of the members' ongoing power - they can't read your confidential state now, and can't change the rules of the service so they could read it in future.

But that's just a general design point, and doesn't affect the suggestion here. I don't think breaking the JS runtime config is a useful freeze, and the sample constitution can add many sensible safeguards that don't break the above capability (consortium can always change the constitution to remove such safeguards if they need to).

@achamayou achamayou removed this from the 4.x milestone Jan 25, 2024
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