Repository navigation
Promise.resolve('import("node:fs")').then(eval) throws TypeError: Invalid host defined options #49726
Description
Version
v20.7.0
Platform
Linux PIG-2016 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
esm
What steps will reproduce the bug?
node -e 'Promise.resolve(`import("node:fs")`).then(eval)'How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
it shouldn't throw.
What do you see instead?
these DONT throw
node -e 'Promise.resolve(`import("node:fs")`).then(x=>globalThis.eval(x))'
node -e 'Promise.resolve(`import("node:fs")`).then(x=>(0,eval)(x))'
node -e 'Promise.resolve(`34`).then(eval)'
node -e 'Promise.resolve().then(eval)'
node -e 'eval(`import("node:fs")`)'
node -e 'globalThis.eval(`import("node:fs")`)'
node -e '(0,eval)(`import("node:fs")`)'
node -e '`import("node:fs")`.replace(/^.*$/s,eval)'these DO throw
node -e 'Promise.resolve(`import("node:fs")`).then(eval)'
node -e 'Promise.resolve(`import("node:fs")`).then((0,eval))'
node -e 'Promise.resolve(`import("node:fs")`).then(globalThis.eval)'jcbhmr@PIG-2016:~$ node
Welcome to Node.js v20.7.0.
Type ".help" for more information.
> Promise.resolve('import("node:fs")').then(eval)
Promise {
<pending>,
[Symbol(async_id_symbol)]: 234,
[Symbol(trigger_async_id_symbol)]: 233
}
> Uncaught TypeError: Invalid host defined options
at eval (eval at processTicksAndRejections (node:internal/process/task_queues:95:5), <anonymous>:1:1)
at eval (<anonymous>)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
>Additional information
deno version of the same thing DOESN'T throw:
jcbhmr@PIG-2016:~$ deno
Deno 1.36.3
exit using ctrl+d, ctrl+c, or close()
REPL is running with all permissions allowed.
To specify permissions, run `deno repl` with allow flags.
> Promise.resolve('import("node:fs")').then(eval)
Promise {
[Module: null prototype] {
Dir: [class Dir],
Dirent: [class Dirent],
F_OK: 0,
O_APPEND: 8,
O_CREAT: 512,
O_DIRECTORY: 1048576,
O_DSYNC: 4194304,
O_EXCL: 2048,
O_NOCTTY: 131072,
...
Activity
aduh95 commentedon Sep 20, 2023
Can you copy paste the output of your console instead of sending screen shots? Screenshots can be very unhelpful for e.g. folks using screen readers and/or folks with visual disabilities.
The following works on most1 runtimes but Node.js:
Footnotes
I'd like to say all, but there are so many runtimes these days I surely missed at least one ↩
[-]`Promise.resolve(`import("node:fs")`).then(eval)` throws `TypeError: Invalid host defined options`[/-][+]``Promise.resolve(`import("node:fs")`).then(eval)`` throws `TypeError: Invalid host defined options`[/+][-]``Promise.resolve(`import("node:fs")`).then(eval)`` throws `TypeError: Invalid host defined options`[/-][+]`Promise.resolve('import("node:fs")').then(eval)` throws `TypeError: Invalid host defined options`[/+]jcbhmr commentedon Sep 20, 2023
jcbhmr commentedon Sep 20, 2023
The two spots I could find from a GitHub search for "Invalid host defined options" are these:
node/src/module_wrap.cc
Lines 572 to 576 in b64f620
node/deps/v8/src/d8/d8.cc
Lines 1252 to 1255 in b64f620
jcbhmr commentedon Sep 20, 2023
aduh95 commentedon Sep 21, 2023
The following check is failing (
options->Length()is supposed to be 9, it's 0 here):node/src/module_wrap.cc
Lines 568 to 569 in 26c8858
Here's a backtrace (maybe I need a debug build):
targos commentedon Sep 22, 2023
host_defined_optionsis empty because of this condition:node/deps/v8/src/execution/isolate.cc
Lines 5113 to 5116 in c2cd744
maybe_referrercomes from here:node/deps/v8/src/runtime/runtime-module.cc
Lines 36 to 37 in c2cd744
joyeecheung commentedon Sep 22, 2023
This is likely a V8 issue, I can also reproduce it with d8. The problem probably comes from that V8 is unable to retrieve the referrer/origin when code is
eval'ed directly from a microtask - if you wrap it in an anonymous function V8 is going to generate bytecode that passes the closure to a runtime call so that it can figure out the script and then the referrer/origin. If it's just eval directly with no JS frames above V8 uses an empty script as the wrapper and cannot infer host-defined options.joyeecheung commentedon Sep 22, 2023
Also this does not only affect host-defined options, for example V8 would not be able to show the script name if an error is thrown from code being eval'ed directly from a microstask because of the same cause. I'll open an upstream issue.
joyeecheung commentedon Sep 22, 2023
Upstream issue https://bugs.chromium.org/p/v8/issues/detail?id=14336
jcbhmr commentedon Sep 22, 2023
@joyeecheung naive question: if it's a V8 problem then why doesn't Deno (also V8-based) have this issue? 🤔 is deno doing some magic or something?
aduh95 commentedon Sep 22, 2023
FWIW Chromium is also not affected. Even if it is not a V8 issue in the end, the patch that will fix d8 will probably contain all the needed info to fix it in Node.js, so I think our best course of action is to wait for V8 team for a fix.
6 remaining items
joyeecheung commentedon Sep 26, 2023
I think the answer to whether we should fallback comes down to:
importModuleDynamicallyfallback in this case too? That would make escaping the configured hook possible, so at least warrants a note in the doc. This may also apply to custom loaders @nodejs/loadersjoyeecheung commentedon Sep 27, 2023
Actually I think the editor notes does not apply to microtasks, from https://262.ecma-international.org/14.0/#sec-hostenqueuepromisejob the implementation should restore the active script from when the microtask is queued
legendecas commentedon Oct 9, 2023
@joyeecheung this is interesting. I tested on Chrome 117, Firefox 119, and Safari 17, none of them respected this statement. They resolve eval import calls relative to the origin of the document, rather than the initiating module. I believe either the ecma262 has to be corrected to reflect the web reality, or the browsers have to fix the behavior.
ljharb commentedon Oct 9, 2023
I’m confused; why would anyone expect this to work? This would attempt to eval the toString of the module namespace object, and you simply can’t assume eval of any function will be portable.
legendecas commentedon Oct 9, 2023
@ljharb it's not about eval-ing the toString result of a module namespace. The problem here is how to resolve the specifier when the eval function is called with a string script containing dynamic imports and the eval function is invoked by built-in callbacks directly.
aduh95 commentedon Oct 10, 2023
I just noticed the HTML spec deals with this exact situation in https://html.spec.whatwg.org/multipage/webappapis.html#hostmakejobcallback
joyeecheung commentedon Oct 11, 2023
Interesting, apparently WHATWG spec is explicitly saying that in this case the referrer should be the original script (and, on the contrary, if it's from a
onclickhandler, there's no original script), while browsers don't actually implement that behavior..bmeck commentedon Oct 11, 2023
@joyeecheung they took this to TC39 at one point but TC39 members had some concerns about the behavior because it could lead to an exploit by giving extra permissions to the eval'd string
From July 2020: https://docs.google.com/presentation/d/19S97ZqhibJABqzeP5ZU6Flk6TVgWzXuvJWFbNTTfpWs/edit#slide=id.p
legendecas commentedon Oct 13, 2023
Submitted tc39/ecma262#3195 to propagate active scripts with arbitrary microtask callbacks (like FinalizationRegistry callbacks) in ecma262.
vm: allow dynamic import with a referrer realm
vm: allow dynamic import with a referrer realm
vm: allow dynamic import with a referrer realm
vm: allow dynamic import with a referrer realm