Rewrote CSP & EcmaScript integration

[mikesamuel]

This reworks how new Function(source) and eval(source) are
checked against a CSP and Trusted Types policy.

It trusts TrustedScript when the relevant CSP policies and TrustedType
configurations agree on whether to enforce and the TrustedType
configuration places limits on policy creation.

It also changes the previous language to use calleeRealm instead of
callerRealm for consistency with other sinks.

  let f = new self.top.Function(source);

In this case, the callerRealm's Window is self and the
calleeRealm's Window is self.top.
The Trusted Types portion of this algorithm uses calleeRealm
for consistency with other sinks.

  // Assigning a string to another Realm's DOM sink uses that
  // Realm's default policy.
  self.top.body.innerHTML = 'Hello, World!';
  // Using another Realm's builtin Function constructor should
  // analogously use that
  // Realm's default policy.
  new self.top.Function('alert(1)')()

It also makes recent versions of bikeshed run without warnings.

Fixes #143
Issue #144

[mikesamuel]

@mikewest This is what we discussed via email.

@otherdaniel @koto Fyi, this has a normative change to the realm used.

[koto]

The name might be a bit misleading, IIUC this is not checking the policy disposition, but whether any of the CSPs (enforcing, or report-only) cover script-src without 'unsafe-eval'.

[mikesamuel]

Um. isCSPEnforced should mean

∃ p. !isReportOnly(p) and 'unsafe-eval' not in p

If not, that's a spec bug.
What do you think of the name given that goal?

[koto]

The name is fine (there's just no check for report only here, I think).

[koto]

Why do you calculate & check for isCSPEnforced here? Can't eval(TrustedScript) be exempt from CSP restrictions if isTTStrict and isTTEnforced under script-restricting CSP, and always otherwise?

IIUC, that would happen if you don't do any CSP-related calculations in this algorithm. EnsureCSPDoesNotBlockStringCompilation will enforce any CSP restrictions if this algorithm returned false, which may simply do nothing if there are no CSPs set.

What usecase does the condition in this step cover?

[mikesamuel]

I'm looking for consistency between enforcement, because I want testing with TT & CSP in report-only mode to only report violations during normal use that need to be fixed to avoid violation reports with enforcement on during normal use.

So I worry that if I don't check for consistency between TT and CSP that an engineer migrating would see CSP report-only violation reports that would be suppressed by the is-exempt check were TT and CSP both in enforce mode.

If that sounds like a good goal, maybe this deserves a note.

[koto]

So this assumes you're swapping the CSP enforcement together with TT enforcement? For example, if you have enforcing TT and report-only CSP, this will generate violations that you have no way of fixing, which would disappear when CSP is enforced.

In general, during rollouts it would be rare to have the disposition of both CSP and TT to be changed simultaneously.

[mikesamuel]

I rebased and rewrote to recognize script-src: 'trusted-script'.

[mikesamuel]

Ack. Just noticed that I need to rewrite IsSourceExempt. It should simplify a lot since there's no need to distinguish between strong and weak TT configurations.