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

import-bundle: allow symbol-named properties in inescapableGlobalProperties #2376

Closed
warner opened this issue Jul 23, 2024 · 1 comment · Fixed by #2377
Closed

import-bundle: allow symbol-named properties in inescapableGlobalProperties #2376

warner opened this issue Jul 23, 2024 · 1 comment · Fixed by #2377
Assignees
Labels
enhancement New feature or request performance

Comments

@warner
Copy link
Contributor

warner commented Jul 23, 2024

What is the Problem Being Solved?

As discussed in the comments on #1676, we'd like to convey passStyleOf into vat environments via a symbol-named property on the global, rather than a string-named property on VatData.

To support this, we need to change import-bundle to pay attention to symbol-named properties of inescapableGlobalProperties, because currently it uses Object.keys, which ignores symbols and only copies the string-named properties into the child Compartment's global. We'll accomplish this by using Reflect.ownKeys

While we're at it, we'll change import-bundle to look for all own properties of inescapableGlobalProperties, not just the enumerable ones (which matches the change from Object.keys to Reflect.ownKeys).

Description of the Design

Add tests. Change it to use Reflect.ownKeys.

Security Considerations

None I can think of, whoever is calling importBundle is in control of what properties they put on inescapableGlobalProperties, so if they want to make those properties unenumerable or Symbols, that's their business. And that party is in complete control over the guest/Compartment code's world.

Scaling Considerations

none

Test Plan

unit tests

Compatibility Considerations

In the unlikely event that someone was already using Symbol-named properties, or unenumerable ones, in their inescapableGlobalProperties call, their guest code will start getting access to new properties, perhaps suprisingly. But that seems quite unlikely.

Upgrade Considerations

To benefit from this, the host code must start using a new version of import-bundle. For the Agoric chain, that means a new version of swingset-xsnap-supervisor, so the process is:

  • do a chain-halting upgrade that includes the new supervisor
  • create a new vat, or upgrade an existing vat, both of which will then use the new supervisor code
  • (also use a new liveslots, to get the passStyleOf endowment, and a new/current @endo/pass-style, which pulls that endowment)
@warner warner added enhancement New feature or request performance labels Jul 23, 2024
@warner warner self-assigned this Jul 23, 2024
warner added a commit that referenced this issue Jul 23, 2024
…balProperties

Previously, the `inescapableGlobalProperties` option to
`importBundle()` only accepted enumerable string-named
properties. This commit changes that to accept all properties (even
unenumerable ones), and to accept symbol-named properties (instead of
only string-named ones).

We'll use this to provide `passStyleOf` to the vat environment built
by liveslots, so it can use a real WeakMap, instead of the (slower)
"virtual object -aware WeakMap".

closes #2376
@gibson042
Copy link
Contributor

Related: Agoric/agoric-sdk#9781

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants