TC39 Module Harmony
2022-07-13
plaintext logs
prev next
source on github
02:11
<Kris Kowal>
Maybe should call it Compartment and build up from there.
09:02
<Kris Kowal>
new Evaluators({globalThis, importHook}) => {eval, Function, Module} seems good.
09:05
<Kris Kowal>
It’s certainly better than Shire or Fiefdom.
09:06
<Kris Kowal>
The latter should obviously be reserved: ”Fiefdom: A Realm that has -DOM”.
09:07
<Kris Kowal>
Oh, silly me. That joke works just as well with Kingdom.
13:21
<littledan>
What is the purpose of the eval and function hooks? Is this about them leaking the global object?
13:22
<littledan>
I guess if we're not allowing arbitrary hookability, but just making sure they are hooked up to the right global, then the Thing interface you describe above seems fine to me
13:24
<littledan>
I'm trying to understand whether the importHook that you pass into Thing is the same as the one you pass into Module
13:48
<Jack Works>

I implemented ExecutionContext and Module in@masknet/compartment 0.2.0.

No eval Function or ModuleSource support, only support Virtual Module

13:48
<Jack Works>
plz play around and it will be good to have some feedback
14:27
<Kris Kowal>
littledan The new eval executes in a scope that ends with the given global object and in which dynamic import is virtualized by the given importHook, just like modules. The new Function creates function instances that also execute in a script context captured by the given global and import behavior. The new Module constructor creates modules that are captured by the given global, and could conceivably use the given import hook as a default. That would imply that the intrinsic Module constructor would by default have the host-defined import behavior.
14:30
<Kris Kowal>
An Evaluators constructor would be necessary and not sufficient to isolate dependencies. Evaluator, Module, and ModuleSource together are sufficient to reconstruct a much smaller and more perfect SES shim (hardened JavaScript)
14:31
<Kris Kowal>
Lockdown and Compartment can be shimmed from those components.
14:31
<Kris Kowal>
And notably, with module blocks or import-module-source syntax, that would even play well with CSP.
14:33
<Kris Kowal>
Currently, as Jack Works can testify, isolating dependencies in a no-unsafe-eval environment requires a much larger trusted-compute-base, one that goes out to the bundle generator and its transitive dependencies, naturally including a JavaScript parser and generator framework. Much greater exposure to supply chain attacks.
15:18
<Jack Works>
🤔 actually if we runs in no-unsafe-eval, the runtime will be much simpler because no evaluator is allowed. my trusted base only includes swc (a JS compiler written in Rust)
18:17
<nicolo-ribaudo>

Do eval/Module/Function on new Evaluators() get their intrinsics from the globalThis parameter? For example

function MyArray() {}
const myGlobalThis = { Array: MyArray };
new Evaluators(myGlobalThis, importHook).eval("[]") instanceof MyArray; // ?
19:20
<Kris Kowal>
No, they get the intrinsics of the realm, except for eval, Function, and Module.
19:21
<Kris Kowal>
Another way of framing it is that eval, Function, and Module are intrinsic to the evaluator and all others are intrinsic to the realm.
19:22
<Kris Kowal>
I imagine this works by changing [[Realm]] on Execution Context to point to [[Evaluators]] and Evaluator Record to point to [[Realm]].