Skip to content

Commit

Permalink
As of tc39/ecma262#3222 the signature of HostEnsureCanCompileStrings …
Browse files Browse the repository at this point in the history
…changed. This updates the spec to better reflect the current state.

This also updates the README accordingly.
  • Loading branch information
lukewarlow committed Feb 20, 2024
1 parent 0e3b124 commit abc4a10
Show file tree
Hide file tree
Showing 4 changed files with 1,975 additions and 774 deletions.
37 changes: 5 additions & 32 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -149,9 +149,9 @@ but without changing the semantics of pre-existing programs.
## Problem 2: Host callout does not receive type information

Currently the information available to decide whether to allow compilation of
a string is a pair of realms.
a string is a realm, a list of strings from parameters, a string from body, and a boolean.

> HostEnsureCanCompileStrings( _callerRealm_, _calleeRealm_ )
> HostEnsureCanCompileStrings( __calleeRealm_, _parameterStrings_, _bodyString_, _direct_ )
>
> HostEnsureCanCompileStrings is an implementation-defined abstract
> operation that allows host environments to block certain ECMAScript
Expand All @@ -178,43 +178,16 @@ the Function constructor arguments passed the `IsCodeLike` check.

- Requires changes to the host callout (see also below):

## Problem 3: Host callout does not receive the code to check
## Problem 3: Host callout does not receive the full code to check

`HostEnsureCanCompileStrings` only passes the realm. In the web platform,
that callout is hooked to the [Content Security Policy algorithms](https://w3c.github.io/webappsec-csp/#should-block-inline"), which take action based on _code_ that is to be executed - e.g. an eval() argument, or a dynamically-created function body, to be able to include that code in [violation reports](https://w3c.github.io/webappsec-csp/#security-violation-reports) ([CSP3's issue 8](https://www.w3.org/TR/CSP3/#issues-index))

As such, some implementations (v8 and SpiderMonkey) actually also pass the code string
to the host, and in the case of <code>new Function()</code> perform the callout
later in `CreateDynamicFunction`, after the function body is assembled.
`HostEnsureCanCompileStrings` is called with parameters for the source code, but they're not in a unified string.

### Solution

This proposal updates the host callout to contain the code string to be executed,
This proposal updates the host callout to contain the full code string to be executed,
and moves the callout in `CreateDynamicFunction` after the function body is
assembled.

### Spec / implementation mismatch

Moving the callout in CreateDynamicFunction changes the behavior in
implementations that specify a non-default host callout.

Currently the stringifier should not execute if the host disables the string
compilation:

```javascript
new Function({
toString: () => {
throw "Should not happen, as the callout would reject this earlier";
},
});
```

Current implementations differ in behavior. For example, v8 and Spidermonkey
are not ES spec-compliant. JSC follows the spec - [In-browser proof of concept](https://gadgets.kotowicz.net/poc/createdynamicfunction.php).

This proposal would cause the stringifier to execute _before_ the callout,
making it possible for the browser hosts to actually follow the CSP spec.

## Problem 4: Host callout cannot adjust values

Trusted Types defines a [default policy][] to make it easier to
Expand Down
Loading

0 comments on commit abc4a10

Please sign in to comment.