-
Notifications
You must be signed in to change notification settings - Fork 71
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(ses,module-source): Add ModuleSource shim #2463
Conversation
98d1cbd
to
2e47ef8
Compare
if (globalThis.ModuleSource) { | ||
const AbstractModuleSourcePrototype = getPrototypeOf( | ||
globalThis.ModuleSource.prototype, | ||
); | ||
intrinsics['%AbstractModuleSourcePrototype%'] = | ||
AbstractModuleSourcePrototype; | ||
intrinsics['%AbstractModuleSource%'] = | ||
AbstractModuleSourcePrototype.constructor; | ||
} |
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.
A valid but annoying feedback reviewers might provide here is that we can’t anticipate whether ModuleSource
will land in the language with or without an AbstractModuleSource
on its prototype chain, so we could hedge our bets and add a repair for ModuleSource to force it to appear one way or the other, so that lockdown()
doesn’t break if the AbstractModuleSource is absent. Or, we could go the other way and not have AbstractModuleSource by default, in which case SES would just delete it and issue a warning if it showed up.
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.
You read my mind, but that's just the risk with front-running proposals. No suggestion.
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.
Capturing here my reasoning for keeping AbstractModuleSource since it appears to be the path of least regret.
- We shim AbstractModuleSource and include it in SES permits:
- The application includes module-source/shim.js:
- The VM implements AbstractModuleSource: ✅ Lockdown’s fine
- The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine. The shim currently stomps the native implementation. If it didn’t stomp the native implementation, Lockdown would tolerate the incomplete intrinsics.
- The application excludes module-source/shim.js:
- The VM implements AbstractModuleSource: ✅ Lockdown’s fine
- The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine, but intrinsics are incomplete
- The application includes module-source/shim.js:
- We do not shim AbstractModuleSource and exclude it in SES permits:
- The application includes module-source/shim.js:
- The VM implements AbstractModuleSource: ✅ :man-shrugging: The shim currently stomps the native implementation, so this works out. But, if the shim surfaced the native implementation (and perhaps feature-checks that the native implementation behaves just like the shim deigning to fall through to native)
- The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine
- The application excludes module-source/shim.js:
- The VM implements AbstractModuleSource: 💔 Lockdown is surprised to find AbstractModuleSource and chooses throw rather than attempt a repair. We don’t have the module source shim in play, so there’s nothing it can do to mitigate. We can’t require the module-source/shim.js because it entrains Babel.
- The VM does not implement AbstractModuleSource: ✅ Lockdown’s fine
- The application includes module-source/shim.js:
fb9a58e
to
928cd19
Compare
928cd19
to
8f6291d
Compare
8f6291d
to
f78f9d9
Compare
Refs: #2252
Description
To test feature the degree of compatibility between a version of XS, XS with Endo shims, and Node.js with Endo shims, we need a shim for ModuleSource proper. This lets us create an environment with a global
ModuleSource
, whereModuleSource
is a shared intrinsic of all Compartments.This change both introduces the shim and the necessary accommodations for the existence of a global ModuleSource shared intrinsic in SES.
Security Considerations
The new ModuleSource is subject to hardening of shared intrinsics during SES lockdown. A failure to harden the shared intrinsic would lead to a potential for interference or communication between isolated compartments.
Scaling Considerations
None.
Documentation Considerations
None.
Testing Considerations
This includes a test for SES that verifies that ModuleSource is properly propagated and hardened.
Compatibility Considerations
None.
Upgrade Considerations
None.