Cannot build self-contained no_std application using getrandom 0.3+ due to `RUSTFLAGS` `--cfg getrandom_backend` requirement

[ColinFinck]

Disclaimer: I have read #670, #671, #672, #684, #725, #746, but to my knowledge, this nuance of problems with --cfg getrandom_backend has not been brought up yet.

I'm developing a self-contained no_std application using getrandom. It doesn't run on a popular operating system, hence none of the conditions in src/backends.rs are fulfilled and I usually end up in

getrandom/src/backends.rs

Lines 179 to 182 in 22082f2

	compile_error!(concat!(
	"target is not supported. You may need to define a custom backend see: \
	https://docs.rs/getrandom/", env!("CARGO_PKG_VERSION"), "/#custom-backend"
	));

With getrandom 0.2, my application could declare a dependency on getrandom's "custom" feature in its Cargo.toml and add a call to register_custom_getrandom! in its main Rust source file. That was everything required to support my no_std scenario.
Anyone could download my Rust project and build it using cargo build.

With getrandom 0.3 and newer versions, people are no longer able to do this. By default, they always get a "target is not supported" error during build. Even worse, there seems to be no reasonable way around this:

• I could tell my users to set RUSTFLAGS='--cfg getrandom_backend="custom"'. Ignoring the bad ergonomics of this extra step, it also overwrites any other RUSTFLAGS set: There's no command that just sets the additional flags required for getrandom. Thinking into the future, this would mean I need to type a long line to set the flags for my application, and for getrandom, and for possibly any other crate that adopts this pattern. All in all, this pattern doesn't scale across crates.

• I could add a [target...] section in a .cargo/config.toml file, set rustflags there, and commit that file along with my application code. However, I would need to do that for any potential target. Being a no_std embedded application, the possible targets are numerous, and it's close to impossible to provide an exhaustive list. All in all, this pattern doesn't scale across targets.

It should also be noted that users sometimes like to play around with RUSTFLAGS, or need to for reasons like compiler settings. They should be able to do that fearless without risking to overwrite crate-specific settings.

• My last attempt was to add a build.rs to my project along with a println!(r#"cargo:rustc-cfg=getrandom_backend="custom""#); line. However, this configuration isn't propagated to the getrandom crate. I still get the same "target is not supported" error.

What can we do to get back the ergonomy of getrandom 0.2?

I want my application to define its entropy source in the code once and be done with it. No user should ever need to look into the specifics of getrandom and its flags.

[newpavlov]

I could add a [target...] section in a .cargo/config.toml file, set rustflags there

You can set rustflags for all targets using the following config:

[build]
rustflags = ["…"]

I guess #725 could've helped in your case, but it was rejected...

[josephlr]

@ColinFinck do you have a link to any of the example crates? I think the ideal solution for 0.3's API would be to do something in a build.rs script if possible.

The main issue with using Rust features (as documented in all the previous issues) is that features cannot be target-specific (see rust-lang/cargo#1197 which has been open for more than a decade), so if any crate enables such a feature on any target it gets enabled on all targets, which breaks things. See #658 for a longer discussion about this.

I agree that the ergonomics here need an improvement, I'm just wondering what we can do without additional support from Rust/Cargo.

@newpavlov do you think doing something like #725 could work alongside #730? Our discussions there were very focused on the use of JS on wasm32-unknown-unknown, but looking back I feel like I neglected the other no_std use cases. Do we want something like a custom feature which uses a custom backend without a RUSTFLAG?

[newpavlov]

@josephlr
As I wrote during discussions, I don't think we should have both wasm_js and custom-fallback features. If we have the latter, then it should be used for WASM as well.

[josephlr]

I guess my ideal setup would involve a user doing something like:

use getrandom::register_backend;

fn my_backend_impl(...) {
    ...
}

register_backend!("my_backend", my_backend_impl);

And then on unsupported targets:

• If a user provides --cfg=getrandom_backend="foo", use "foo" backend or compiler error if "foo" isn't registered.
• If a platform has no backends registered: we give the "target is not supported" compiler error.
• If a platform has one backend and no --cfg=getrandom_backend: we use the only registered backend
• If a platform has multiple backends: compiler error saying "hey use --cfg=getrandom_backend="

I'm not sure to what extent this is possible, but it would be nice if custom backends were this easy.

[newpavlov]

If a platform has multiple backends

This is the difficult part. Custom backends are based on the linking magic, so when two backends get registered in one application we get the ugly and confusing linking errors. I don't think we can do anything here without a proper language support for such cases.

[josephlr]

@josephlr As I wrote during discussions, I don't think we should have both wasm_js and custom-fallback features. If we have the latter, then it should be used for WASM as well.

I think if we did something to allow custom implementations to "just work" without needing to set --cfg=getrandom_backend, we would want to unify it with the wasm_js feature in the following way:

• Enabling the wasm_js feature effectively registers the wasm_js backend on wasm32-unknown-unknown
• Now, if it's the only backend on that target, we use it by default
• If there's an additional backend registered, we raise a compiler error (unless --cfg=getrandom_backend disambiguates things).

Of course this doesn't mean wasm_js would have to literally use register_backend, it would just have to act "as if" it did.

This way, 99% of the users of wasm32-unknown-unknown who are targeting a web platform only need to do one thing (enabling the wasm_js feature), while we still keep ergonomics for most users of non-standard backends.

[newpavlov]

99% of the users of wasm32-unknown-unknown who are targeting a web platform only need to do one thing (enabling the wasm_js feature)

I disagree with this. I believe users should enable a feature in wasm-bindgen/js-sys and it would handle setup and implementation of the getrandom backend. Depending on decision of wasm-bindgen maintainers this feature may be even enabled by default (probably after getrandom v1.0 release), so getrandom would "just work" on WASM as long as users have wasm-bindgen in their dependency tree. The same would apply to any other "system"/HAL crate.

[josephlr]

99% of the users of wasm32-unknown-unknown who are targeting a web platform only need to do one thing (enabling the wasm_js feature)

I disagree with this. I believe users should enable a feature in wasm-bindgen/js-sys and it would handle setup and implementation of the getrandom backend. Depending on decision of wasm-bindgen maintainers this feature may be even enabled by default (probably after getrandom v1.0 release), so getrandom would "just work" on WASM as long as users have wasm-bindgen in their dependency tree. The same would apply to any other "system"/HAL crate.

I agree that:

• if we can figure out how to get something like register_backend! to work.
• we have buy-in from the wasm-bindgen / js-sys maintainers.

that having the implementation live in wasm-bindgen/js-sys would be ideal for a getrandom 1.0. I just want it to only involve enabling a single feature, I'm ambivalent as to which crate handles such a feature.

[newpavlov]

if we can figure out how to get something like register_backend! to work.

It's literally what #725 does (the macro can be easily added)! The only problem is double registration and AFAIK there is nothing that we can do to resolve it with the current language.

we have buy-in from the wasm-bindgen / js-sys maintainers

IIRC they were open to it when I outlined the proposal.

[dhardy]

• If a platform has one backend and no --cfg=getrandom_backend: we use the only registered backend

This model potentially allows any crate in the build tree to make itself the getrandom backend (but only on platforms without native support and only if no other backend is enabled).

Is this an acceptable risk? The worst case is likely that of a naive user reaching for an easy solution and using an insecure backend, meanwhile users of getrandom may assume that the crate only returns securely-random data or fails.

• If a platform has multiple backends: compiler error saying "hey use --cfg=getrandom_backend="

This could cause some annoying issues (since feature flags are supposed to be additive), but is only a minor issue.

---

My view is that there is no perfect solution here. Possibly we should simply tell downstream users like @ColinFinck that their only options are to push support into getrandom (not good for us from a maintenance perspective) or continue using RUSTFLAGS.

[newpavlov]

Closing as wontfix. Hopefully, ergonomics will be improved in future, see #796.