Ergonomics improvements for alternative backends

[josephlr]

As noted in many issues (#658, bevyengine/bevy#18047, https://users.rust-lang.org/t/getrandom-0-3-2-wasm-js-feature-issue/127584, n0-computer/iroh#3200), the use of a Rust --cfg flag can be unergonomic. See the current docs about this for context.

This is mostly due to how tooling (rustc, cargo, etc...) interact with RUSTFLAGS and the rustc command line. This is exacerbated by the fact that the wasm32-unknown-unknown target cannot have a default supported backend, as it is used in many environments (some of which do not have JavaScript). Leading to an unfortunate situation where, if someone wants to build any code which depends on getrandom targeting wasm32-unknown-unknown, they must:

• Modify Cargo.toml to include:

  [dependencies]
  getrandom = { version = "0.3", features = ["wasm_js"] }

• Modify .cargo/config.toml to include:

  [target.wasm32-unknown-unknown]
  rustflags = ['--cfg', 'getrandom_backend="wasm_js"']

This issue is to explore and evaluate approaches like #670 which seek to improve this story, either in 0.3 or in a future major release. It may turn out we end up keeping the current approach for a future major release, but we should explore all reasonable alternatives.

Requirements

A bunch of the ergonomics issues stem from the requirements for this crate. Some of these requirements might be debatable or less important, but ideally any solution would have the following properties (note that the current approach only has most of these):

• Without using any alternative backend, a user shouldn't have to do anything. All the supported backends should work, and the user should get good error messages if building on an unsupported platform.
• Overriding the default backend should be possible.
• You cannot declare/enable multiple alternative backends (for any given target).
• For security, it should be difficult/impossible for a crate deep in the dependency tree to override the default source of randomness.
• The approach should encourage "leaf" crates (i.e. binary crates) to select the backend, rather than core crates.
• wasm32-unknown-unknown should not be special-cased and should not call JavaScript by default (as the target makes it very clear that cannot be assumed).
• Any dependencies used by an alternative backend should not be present in the user's Cargo.lock if that backend is not being used.
• The approach should be similar or analogous to #[global_allocator], as we are defining a global source of randomness.
• We should not conflict with Tracking Issue for secure random data generation in std rust-lang/rust#130703, and ideally have a solution which works well even if that feature gets stabilized.

[josephlr]

From @newpavlov's comment: bevyengine/bevy#18047 (comment)

Make it so features = ["wasm_js"] activates getrandom_backend="wasm_js" by default

Personally, I am against it. The unfortunate reality is that people unconditionally enable such features in library crates for "convenience" despite strongly worded warnings against it. This breaks builds for users who target non-Web WASM. Even worse, just having wasm-bindgen in project's dependency tree can be problematic in such cases (we had one such user, unfortunately I can not find his comment right now).

I'm inclined to agree, I don't really want to special case wasm_js more than we already have. However, if it turns out this is a huge ecosystem-wide issue, we could consider it without it technically being a breaking change.

[alice-i-cecile]

Good analysis of the problem and requirements. I'm very sympathetic: you're really not handed the right set of tools to solve this directly.

Would it be viable to force users to declare a runtime RNG source using a static or the like? In Bevy, we had a similar set of requirements (only ever set by users, not libraries) for our global error handler and that was the flavor of solution we used.

Obviously this is perf-critical though, so you'd need to be careful with locking data structures.

[newpavlov]

Would it be viable to force users to declare a runtime RNG source using a static or the like?

This does not satisfy the fifth requirement since it allows for a random crate in the middle of your dependency tree to change the entropy source used by your whole application (assuming I understood your idea correctly).

[ChrisDenton]

Would having a new wasm32-unknown-web target help here? That way there's a target that explicitly has web APIs.

[alice-i-cecile]

This does not satisfy the fifth requirement since it allows for a random crate in the middle of your dependency tree to change the entropy source used by your whole application (assuming I understood your idea correctly).

Using something like a OnceLock, you could panic when it's set more than once. That would prevent this sort of attack, assuming you forced every user to explicitly declare an RNG source in their binary to use rand.

[Bluefinger]

Would having a new wasm32-unknown-web target help here? That way there's a target that explicitly has web APIs.

It would greatly benefit specifically for the web case, but not so much beyond that. Being able to define a entropy source backend for something like no_std would still have the ergonomic hit, which is something also trying to be resolved here.

[epage]

It would greatly benefit specifically for the web case, but not so much beyond that. Being able to define a entropy source backend for something like no_std would still have the ergonomic hit, which is something also trying to be resolved here.

I think there are two questions

• What should be done generally
• What can unblock a lot of people to reduce the pressure on resolving this

For the second, that depends a lot on the people being impacted by the change

[josephlr]

Would having a new wasm32-unknown-web target help here? That way there's a target that explicitly has web APIs.

Really what we need is Rust to have a wasm32-unknown-js target which just says: "Hey this is a wasm target which has JavaScript" (i.e. js-sys is valid to use on this target). We can check at runtime to see if we are on Node vs the Web or if a given api is supported. The main issue is that if we are just compiling for wasm32-unknown-unknown there's no way to check if JS exists, you just fail to build with inscrutable compiler errors.

Adding this target would help ecosystem-wide, as many low-level crates could now just implement the desired bindings to the necessary JS APIs without any flags/features/etc... when targeting wasm-unknown-js. @Bluefinger is correct that this only helps with web stuff though.

As to @epage's point, I think the vast majority of people having problems here are having problems due to wasm32-unknown-unknown being an unsupported target. Other folks targeting unsupported targets like x86_64-unknown-none or armv7a-none-eabi already have to build libcore/liballoc so they are much more used to dealing with RUSTFLAGS (and the requirement to set particular flags is less unexpected for folks working on those sorts of projects).

I would be fine with a stopgap solution which mostly only helped for wasm32-unknown-unknown users, be that adding a new target to rustc or some other JS-specific solution.