Inconsistent treatment of base64url-encoded hash sources in CSP vs SRI

[bakkot]

script-src 'sha256-CihokcEcBW4atb_CW_XWsvWwbTjqwQlE9nj9ii5ww5M=' is a valid CSP, per the hash-source grammar. Note the base64url-encoded hash source.

It permits

<script>console.log(1)</script>

per 6.1.11.3. script-src Inline Check (via 6.6.3.3. Does element match source list for type and source?, specifically step 5.2.5.2).

But it does not permit

<script src="data:application/javascript,console.log(1)" integrity="sha256-CihokcEcBW4atb/CW/XWsvWwbTjqwQlE9nj9ii5ww5M="></script>

because in 6.6.1.1. Script directives pre-request check step 1.3.4.1 it says that hashes must match exactly, without checking for possibly different base64 vs base64url encoding.

On the other hand,

<script src="data:application/javascript,console.log(1)" integrity="sha256-CihokcEcBW4atb_CW_XWsvWwbTjqwQlE9nj9ii5ww5M="></script>

while permitted by CSP, would not be permitted by SRI, because SRI's matching algorithm calls for a direct comparison, again without checking for possibly different base64 vs base64url encoding, and the other side of the comparison is base64 encoded per 3.3.1 Apply algorithm to response.

This is pretty silly.

[annevk]

I suspect this is in part a mess because (some?) implementations actually "base64" decode some base64 input rather than "base64" encode something to compare with the base64 input.

https://wpt.fyi/results/content-security-policy/script-src/script-src-sri_hash.sub.html is related to this. That also tests lack of padding enforcement which doesn't seem to be defined. (And is inconsistent with data: URLs.)

Once we figure out what we want to be doing here getting it defined in Infra, e.g., via https://github.com/whatwg/infra/issues/566, would be good I think.

cc @antosart @mozfreddyb