Gate features requiring CSP unsafe-eval on a non-default Cargo feature

[briansmith]

Motivation

wasm-bindgen and its associated crates (js_sys, web_sys, etc.) should be compatible with normal CSP configurations, i.e. ones that don't whitelist unsafe-eval or unsafe-inline. Right now, it is too easy to accidentally to accidentally make a wasm-bindgen-based crate incompatible with good CSP practices. Further, it is hard to audit the internal implementation of wasm-bindgen and its associated crates for CSP problems. See #1641 for example.

Proposed Solution

Create an unsafe-eval Cargo feature that controls access to the Function constructor, eval, and other features that result in JS that would require unsafe-eval. The feature shouldn't be marked as a default feature so that one can easily audit a depending crate's Cargo.toml to see if these features are in use. Instead, bump to the next incompatible version number since this is not a backward-compatible change. Test in CI the default configuration and the configuration with the unsafe-eval feature enabled. Change the implementation of as many APIs as possible to work in the default (non-unsafe-eval configuration, e.g. web_sys::window(). This may require such APIs to be redesigned.

[Pauan]

The feature shouldn't be marked as a default feature so that one can easily audit a depending crate's Cargo.toml to see if these features are in use.

That doesn't work, because it's possible for any library to enable the feature. So you have to check the Cargo.toml of the crate, and all of its dependencies, and all of its transitive dependencies.

In addition, this is trickier than it may seem, because there are quite a few APIs which have implicit eval behavior, and they need to be carefully blacklisted manually (e.g. set_timeout_with_str)

In addition, it's always possible for a crate to use inline_js (or import a module) to do eval, so a feature doesn't actually help.

Personally, I would be in favor of getting rid of all of the eval things completely. There's very very few legitimate uses for eval, and it's always possible to use inline_js if you really truly need eval.