shim: reject dynamic import expressions

[warner]

ES6 module -style import (from module code), at least in a browser environment, could load data from the network, in a way that violates our confinement rules. Until we have a story about how an import trap should work, we need to reject ES6 imports.

Static import statements are already illegal in "script code", and our eval parses the strings as script code. However we need the shim code to reject dynamic import expressions and dynamic import.meta expressions. We can use a regular expression to reject the word import followed by any amount of whitespace or newlines followed by either // or /* or ( or . (the comment-initiating sequences might eventually be followed by a comment-terminator and then the () call). This will reject some otherwise legal comments or literal strings that mention imports (making the dynamic import expression "tahoo": something you can't even talk about in this code, much less invoke).

If there's a parser, for extra credit, just reject when the AST includes an identifier spelled import. This would remove the false rejections.

[ljharb]

What's a "dynamic import.meta expression"? import.meta only exists in Module code.

[warner]

@erights , could you remind me what this note was for? I know it's related to https://github.com/tc39/proposal-import-meta , but as @ljharb said that appears to only be specced to appear in module code, and I don't think our evaluator is providing such an environment.

[caridy]

@ljharb is correct, import.meta is an early error in scripts: https://tc39.github.io/proposal-import-meta/#sec-left-hand-side-expressions-static-semantics-early-errors

As for the import, it is going to be tricky to restrict that. I wonder if we should push for a signal to prevent import from being executed as part of that proposal, similar to Symbol.unscopables or something, or maybe just disabling it inside with statements. It seems that the only way to restrict import today is at the expense of CSP, which itself is not an option for many folks. eval is easy to restrict by nuking its global reference, but import is not. @erights has you thought about this?

[erights]

@ljharb Yes, you're correct. We are deleting the dot from the conservative regexp, whose purpose was to catch this case. Thanks!

[warner]

@jfparadis we addressed this in 2efdf0b, right? Do we feel safe closing this now?

[jfparadis]

The vulnerability has been prevented in the shim. We should close this topic.
We still need a solution to prevent the false positives.
We also need to specify in the specs how imports will be handled. It needs to be in the JS engine to work with node, therefore CSP isn't a good candidate for this.
Do we already have issues to track these?

[caridy]

This is related to the Shim implementation, closing since it was moved into https://github.com/Agoric/realms-shim.