-
Notifications
You must be signed in to change notification settings - Fork 229
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
feat(cosmic-swingset): grant addVaultType based on addr #4641
Conversation
"template": { | ||
"agoricNames": true, | ||
"bank": true, | ||
"namesByAddress": true, | ||
"myAddressNameAdmin": true, | ||
"board": true, | ||
"faucet": true, | ||
"zoe": true, | ||
"vaultFactoryCreatorFacet": true | ||
} |
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.
@michaelfig the keys of this template are supposed to be the things that the client manager waits for before resolving the chainbundle. Is this obsolete as of the notifier-based protocol for home
properties?
Can the loadgen get that notifier?
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.
@michaelfig the keys of this template are supposed to be the things that the client manager waits for before resolving the chainbundle. Is this obsolete as of the notifier-based protocol for
home
properties?
It's mostly orthogonal. Those things are the items that must be present before the first time the notifier fires.
Can the loadgen get that notifier?
Not currently. That would be a good change (always include the notifier as one of the properties on agoric
).
Until then, the template ensures deploy scripts can have access to those objects. Without the template and without the notifier, there is only polling. So let's always ensure one of those is in force.
usage: in a dapp dir, after `agoric install`: agoric start local-solo --reset -v > ,solo.log 2>&1 addr=$(cat _agstate/agoric-servers/local-solo-8000/ag-cosmos-helper-address) VAULT_FACTORY_CONTROLLER_ADDR=$addr \ CHAIN_BOOTSTRAP_VAT_CONFIG=@agoric/vats/decentral-loadgen-config.json \ agoric start local-chain --reset -v
I have verified that this change, granting both |
* chore(run-protocol): grant VaultFactory addVaultType etc. by address * chore(vats): grantVaultFactoryControl permit, config * feat(cosmic-swingset): grant addVaultType based on addr usage: in a dapp dir, after `agoric install`: agoric start local-solo --reset -v > ,solo.log 2>&1 addr=$(cat _agstate/agoric-servers/local-solo-8000/ag-cosmos-helper-address) VAULT_FACTORY_CONTROLLER_ADDR=$addr \ CHAIN_BOOTSTRAP_VAT_CONFIG=@agoric/vats/decentral-loadgen-config.json \ agoric start local-chain --reset -v * chore: grant priceAuthorityAdmin along vaultFactoryCreator Co-authored-by: Mathieu Hofman <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
closes: #4634
I'd like to be sure @mhofman can reproduce my results before moving beyond draft.
Description
Grant access to the VaultFactory creatorFacet to up to one user based on address.
usage
in a dapp dir, after
agoric install
:then you should see
home.vaultFactoryCreatorFacet
and be able to callE(home.vaultFactoryCreatorFacet).addVaultType()
(cf vaultFactory.js).Security Considerations
This mixes a demo / test mechanism in with production
econ-behaviors.js
, which we aim to avoid. But I think it's clear how the least authority needed is granted.Documentation Considerations
IOU an update to env.md
Testing Considerations
It's lightly tested;
packages/vats/test/test-boot.js
does cover it to some extent.cc @michaelfig