How does a vetted shim extend shared global variables?

Every time a new compartment is created, its new global object is initialized by default with a standard set of global variable bindings hard coded in the ses whitelists. However, sometimes to purpose of a vetted shim is to add a new “standard” global that is not standard yet, that should be implicitly propagated to new globals just as Array is. It is not clear how a vetted shim should express this. For legacy vetted shims, it is even less clear how or whether we should automatically infer this.

Correlated with this, host independent vetted shims need not run in the dangerous all powerful start compartment. But they still need to run before lockdown(). Perhaps we support a pattern with user-level libraries, where a new default-powerless compartment is made to run the vetted shims in, and the globals those shims leave behind gets added to the implicitly propagated shared globals. If so, these new globals must also be included in what lockdown() locks down.

[kriskowal]

I would like to investigate this plan:

lockdown remains as-is. We add a repair function that lockdown will call if it hasn’t already been called. We introduce some mechanism for modifying the SES allow-list between repair and lockdown, so an application has an interval in which it can run shims and bless whatever properties it wants to stick afterward.

[Jack-Works]

I believe this becomes urgent. SES lockdown now fails on core-js 3.23 and it cannot be fixed on the core-js side.

See discussion in: https://github.com/zloirock/core-js/issues/1092