fix(provisioning): export useful namesByAddress #8821
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
refs: #8113
(doesn't close it until #8786 lands)
refs: #8786
Description
The
namesByAddress
provided by the provisioning vat is disconnected fromnamesByAddressAdmin
, so it never gets populated.Fortunately, the relevant
nameHubKit
is inbaggage
. So the fix here is to return that one.Security Considerations
This should make it unnecessary for future core-eval scripts to get the whole
namesByAddressAdmin
authority when they only neednamesByAddress
to do something like deliver fees.The permit of the upgrade core-eval is:
Read/write access to the whole
vatStore
is excess authority; we only need access to read one of its entries, not authority to scribble over all the others and upgrade all the other vats. (cc @raphdev )vatAdminSvc
is needed to look up a bundleID (hash) and return the corresponding bundleCap. Its only method beyond that sort of bundle lookup isE(vatAdminSvc).createVat()
. That method is more than we need, but while it can be wasteful, it doesn't pose any risk to integrity.Scaling Considerations
n/a
Documentation Considerations
fixes the chain to agree with our docs on name services
Testing Considerations
Includes a unit test.
The upgrade proposal here works on a release branch (see #8786) but won't work on master due to a breaking change in
@endo/patterns
(#8826). So we don't have a test that runs it.Upgrade Considerations
The bug is localized to the provisioning vat, so upgrading it seems to suffice.
Perhaps we should fix #8408 while we're at it?