You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
…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
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 ofinescapableGlobalProperties
, because currently it usesObject.keys
, which ignores symbols and only copies the string-named properties into the child Compartment's global. We'll accomplish this by usingReflect.ownKeys
While we're at it, we'll change
import-bundle
to look for all own properties ofinescapableGlobalProperties
, not just the enumerable ones (which matches the change fromObject.keys
toReflect.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 oninescapableGlobalProperties
, 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 ofswingset-xsnap-supervisor
, so the process is:passStyleOf
endowment, and a new/current@endo/pass-style
, which pulls that endowment)The text was updated successfully, but these errors were encountered: