-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: Provide source text to HostEnsureCanCompileStrings #3222
Normative: Provide source text to HostEnsureCanCompileStrings #3222
Conversation
cc @mikesamuel |
d07cd69
to
8b2f141
Compare
2a8a0a0
to
a4dbfc8
Compare
9659303
to
a0c6261
Compare
Updated to reflect the consensus in TC39 plenary of 2023-11-27:
|
thanks for the update @ptomato, this is looking good! |
a0c6261
to
e149547
Compare
I've updated this to reflect the option that had the most support in today's plenary meeting: passing the body string to the host hook after stringifying it. (I've also removed the references to #1498 from the commit message and reset the author; this PR no longer subsumes the goal of #1498, and in fact has ship-of-Theseus'ed so that it now contains nothing from the original) cc @erights for further discussion |
e149547
to
82fc88b
Compare
82fc88b
to
f3bc8eb
Compare
Note that Firefox, Safari and Chrome already implement Option 2. Test case: <html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline'">
</head>
<script>
new Function({
toString: () => {
console.log("Should not happen");
return "return 2"
},
});
</script>
</html> All the three browsers log before throwing. The observable change introduced my option 2 would thus just be matching web reality :) |
For posterity, "option 2" refers to this slide. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(note: do not merge yet because we haven't had the chance to talk about this with MM, which he asked to do before merging)
1ebabde
to
db61ea2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks okay to me.
639273d
to
af086c8
Compare
@tc39/ecma262-editors I realized this one wasn't in the list of things that would be added before ES2024 is cut. But I believe all of the discussions have been resolved, is there anything else preventing it from making the cut? |
) This change provides the source text to be evaluated, and the grammar symbol that should be used to parse it, to the host hook HostEnsureCanCompileStrings. One example of where this is needed is for allowing a Content Security Policy to provide hashes for code executed via `eval()` or `new Function()`: w3c/webappsec-csp#623 This is useful on its own, but has come up again in the topic of ShadowRealm-HTML integration. In a ShadowRealm you can either execute code asynchronously, with ShadowRealm.p.importValue, or synchronously, with ShadowRealm.p.evaluate. Because the latter uses `eval()` inside the ShadowRealm, it's subject to CSP rules, so the only CSP policy that will let you execute synchronously in the realm is `unsafe-eval`. This is a separate needs-consensus PR, rather than being part of the ShadowRealm proposal, because it's useful independently of ShadowRealm, and also ShadowRealm would go forward regardless of whether this goes forward. Prior art: https://github.com/tc39/proposal-dynamic-code-brand-checks
af086c8
to
b07ca06
Compare
As of tc39/ecma262#3222 the signature of HostEnsureCanCompileStrings changed. This adapts to the new signature by pulling in the latest version of ecma262-biblio and adding the missing arguments. Closes: tc39#367
As of tc39/ecma262#3222 the signature of HostEnsureCanCompileStrings changed. This adapts to the new signature by pulling in the latest version of ecma262-biblio and adding the missing arguments. Closes: #367
…changed. This updates the README to reflect the current state.
…changed. This updates the spec to better reflect the current state.
…changed. This updates the spec to better reflect the current state. This also updates the README accordingly.
…changed. This updates the spec to better reflect the current state. This also updates the README accordingly.
…changed. This updates the spec to better reflect the current state. This also updates the README accordingly.
…changed. This updates the spec to better reflect the current state. This also updates the README accordingly.
This is based on Mike Samuel's work in #1498, but ultimately goes in a different direction. Due to #2670, this change can be made simpler than it previously was.
This change provides the source text to be evaluated, and the grammar symbol that should be used to parse it, to the host hook HostEnsureCanCompileStrings.
One example of where this is needed is for allowing a Content Security Policy to provide hashes for code executed via
eval()
ornew Function()
:w3c/webappsec-csp#623
This is useful on its own, but has come up again in the topic of ShadowRealm-HTML integration. In a ShadowRealm you can either execute code asynchronously, with ShadowRealm.p.importValue, or synchronously, with ShadowRealm.p.evaluate. Because the latter uses
eval()
inside the ShadowRealm, it's subject to CSP rules, so the only CSP policy that will let you execute synchronously in the realm isunsafe-eval
.The original purpose of #1498 was to support Trusted Types, which is still a goal of this PR.This is a separate needs-consensus PR, rather than being part of the ShadowRealm proposal, because it's useful independently of ShadowRealm, and also ShadowRealm would go forward regardless of whether this goes forward.
Prior art: https://github.com/tc39/proposal-dynamic-code-brand-checks