Re: wasm-unsafe-eval script-src directive

Am 10.12.19 um 21:23 schrieb Daniel Veditz:
> On Tue, Dec 10, 2019 at 11:19 AM Charles Vaughn <cvaughn@gmail.com
> <mailto:cvaughn@gmail.com>> wrote:
> 
>     I'm a dev at Tableau, and Mike West pointed me here after a PR I
>     made to enable this for Chrome. For background, this is the proposal
>     here: https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md#proposed-wasm-unsafe-eval-directive  
> 
> 
> Thanks for the work that went into this plan.
> 
> wasm-unsafe-eval, or maybe even just 'wasm-eval' seems reasonable.
> 
> The hash bit needs work -- on our side more than in your proposal. We
> don't want to calculate the hash over streaming resources, and currently
> don't support SRI for fetch. 

fetch() does support an integrity option, but it does not support
streaming really well. See
<https://fetch.spec.whatwg.org/#dom-requestinit-integrity>


But what I find a bit problematic, is that when a policy has a hash
digest in its script-src directive this proposal makes it completely
unclear whether that's supposed to match a JS file or a WASM file. It
adds complexity, because now every script load and every wasm load needs
to consult the list of hashes. When it would be more performant if there
were two lists of hashes, so we'd know if we had to apply checks for
scripts or wasm (or both).

It almost sounds like we want a separate _directive_ for wasm, rather
than a flag inside script-src.

Received on Wednesday, 11 December 2019 09:19:43 UTC