feat(ses): Tame ModuleSource

[kriskowal]

Refs: #2463, #2252

Description

In #2463 we introduced ModuleSource to the SES permits, but this interacted catastrophically with the native XS ModuleSource. We reverted this change #2468 to unbreak Agoric SDK integration. This change reintroduces the ModuleSource permits, such that they are compatible with both XS and the @endo/module-source/shim.js, which anticipates the introduction of an AbstractModuleSource base class. Because SES can more gracefully tolerate the absence of an permitted [[Proto]] than the presence of a non-permitted [[Proto]], this adjusts the shim to ensure that the AbstractModuleSource shape exists as a side-effect of repairs/taming, before permits are applied.

Security Considerations

None.

Scaling Considerations

None.

Documentation Considerations

This change reintroduces a note in NEWS.md for the next release.

Testing Considerations

The prior regression went unnoticed because we did not yet have CI for XS #2465. With this change, yarn test:xs in SES validates the shim on XS. We also test @endo/module-source/shim.js in ses/test/module-source.test.js on Node.js.

Compatibility Considerations

This change is designed to tolerate either path forward for the language, whether or not it accepts an AbstractModuleSource base class.

Upgrade Considerations

None.

[kriskowal]

Agoric SDK integration probe Agoric/agoric-sdk#10144

[erights]

One thing I don't understand. lockdown calls the repair, to repair things once we have a ModuleSource, whether natively or via the shim. But what brings in the shim? I expected lockdown to do that as well.

[erights]

Why is everything failing under CI?

[kriskowal]

Why is everything failing under CI?

It looks like adding = undefined to the ModuleSource = undefined destructure caused an error in the ModuleSource transform when applied to build dist/ses.*.js. I’m removing the = undefined to verify that’s the root cause, but that is not the end of that investigation. I have probably stumbled into a bug in the module-to-program transform.

One thing I don't understand. lockdown calls the repair, to repair things once we have a ModuleSource, whether natively or via the shim. But what brings in the shim? I expected lockdown to do that as well.

We do not bring in the ModuleSource shim unconditionally because it entrains Babel, so Lockdown must work whether there’s a native ModuleSource, shimmed ModuleSource, or none at all.

[kriskowal]

I’ve restructured this change around addIntrinsics and tameModuleSource instead of any code in getAnonymousIntrinsics. I learned that we need to bind globalThis.ModuleSource at time of lockdown or we get too picky about whether the ModuleSource shim initializes before or after SES. This is ready for another review.

[erights]

LGTM!