Figure out how to manage future `getrandom` upgrades

[KodrAus]

It looks like getrandom's 0.3.x release treats wasm targets a bit differently than 0.2.x. In uuid, we just require a js feature to support RNG in wasm32-unknown-unknown via getrandom, which sniffs out web crypto APIs. In 0.3.x, it looks like you need to set RUSTFLAGS to make this work. If we upgrade our version of getrandom, we'll break existing users of it via the js feature.

We may just need to vendor in the old getrandom impl, so long as we can still compile getrandom 0.3.x on wasm32-unknown-unknown without setting RUSTFLAGS.

[ChrisDenton]

Why not vendor in the new getrandom impl? That would allow skipping the environment variable check?

As far as I can see this crate only uses getrandom::getrandom (aka getrandom::fill in 0.3) so it seems like it'd be simple enough?

[KodrAus]

That looks like it could work 👍 If getrandom won’t compile for the wasm target without the RUSTFLAGS (I haven’t tried it yet) then we might be able to cfg it out for that target. It would depend on how that interacts with optional feature enablement.

So, I think we just have to try something and see how it works out.

[ChrisDenton]

Ok, so to sum up, the official way to do this in getrandom 0.3 is to simply change from the js feature to the wasm_js feature in Cargo.toml:

- js = ["dep:wasm-bindgen", "getrandom?/js"]
+ js = ["dep:wasm-bindgen", "getrandom?/wasm_js"]

But then to actually use it the end user targetting wasm32-unknown-unknown has to have a config.toml containing:

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

Otherwise no getrandom backend will be found and a compile_error! message explaining the issue will be emitted with a link to the getrandom docs:

error: The wasm32-unknown-unknown targets are not supported by default; you may need to enable the "wasm_js" configuration flag. Note that enabling the wasm_js feature flag alone is insufficient. For more information see: https://docs.rs/getrandom/#webassembly-support

---

So one option would be for uuid to add a target.cfg to the getrandom dependency and then vendor the wasm-js file for wasm32-unknown-unknown specifically. I think this will work with optional features.

The other option would of course be to not do anything special because people will probably need to add the --cfg in any case as they update other dependencies that rely on getrandom (either directly or indirectly). This is less desirable but maybe inevitable?

[KodrAus]

I think it was a bit of a lazy mistake on my part for us to rely so directly on getrandom to support WASM, so I'm keen to disentangle uuid from it. While getrandom is unstable there's no guarantee the mechanism it uses won't change again in the future, which they're fully entitled to do.

So one option would be for uuid to add a target.cfg to the getrandom dependency and then vendor the wasm-js file for wasm32-unknown-unknown specifically. I think this will work with optional features.

This sounds like it should work 👍 We can then also call out in our docs that uuid doesn't guarantee getrandom will be used as a source of randomness, so configuring its backend is not guaranteed to affect UUID generation.

[ChrisDenton]

One other issue I just noticed is that the fast-rng feature uses rand::random which will suffer from the same issue.

[KodrAus]

On WASM I think we can make that feature a no-op and continue to use our vendored code instead. It's mostly useful on Windows where the system crypto APIs are surprisingly slow

[ianthetechie]

That seems logical... I ended up accidentally stumbling on this after going down a bit of a rabbit hole to upgrade some dependencies today 😅 (Unfortunately, I do currently have to maintain a direct dependency on getrandom for a wasm build of a library, but I also depend on UUID, and upgrading with feature changes broke my cargo config as there are now 2 getrandom deps in my tree; one from uuid and one explicit).

[KodrAus]

I'm working through this now 👍 I think the scenarios we're still likely to break are those using getrandom on wasm32-unknown-unknown that are actually setting a source for getrandom. If we hit any of those I think we should be able to find a workaround.

[VorpalBlade]

Won't this still break it for no-std that isn't wasm? E.g microcontrollers. We sometimes have to deal with UUIDs in network protocols still. I don't personally need the rng, but I see no reason you couldn't hook it up to a simple shift register or a true hardware rng on a microcontroller if your project needs that.

Perhaps you should simply consider bumping your own major version instead? That seems like the only right way to do this.

[KodrAus]

uuid is a widely used public dependency so bumping our major version and forking the Uuid type would be a much worse state of affairs for everyone.

Users in other no-std environments can still upgrade getrandom too and follow its new docs, since we do technically still use it, but I’d also be interested to explore an API in uuid itself to configure its source of randomness, and possibly time too so we don’t rely on a common unstable dependency to wire this up.

[mitsuhiko]

So I ran into the same problem outside of uuid and I'm not sure how to progress here. It surely can't be the solution that everybody implements their own version of getrandom. Maybe this is the point where some folks could go together and build a more aligned getrandom replacement with clearly defined goals so that it can become a foundation to uuid and other crates?

[KodrAus]

@mitsuhiko The piece that’s missing here is a stable interface to configure randomness on platforms that don’t have an obvious source. That seems like something we could all solve in a way that’s independent of getrandom’s own semver releases.

Yeh it would be a terrible midpoint for everyone to go and define their own interface. It would make trying to configure a project of any meaningful size on a non-standard platform a total pain.

[KodrAus]

For this release and getrandom 0.3, we're going to kick the can down the road. If you're using getrandom in a no-std environment, you can update your version of it and things will continue to work as they did before. Independently, we should look at what a stable interface for configuring randomness may look like, which might involve enshrining how getrandom does it, something in the standard library, or something entirely different. We'll try figure that out before we catch up to the can.

If you're specifically in wasm32-unknown-unknown, but not in an environment with JS to use the js feature, and want to use v4/v7 features of uuid, then we can use some Cargo trickery to make that possible via getrandom too, without breaking the existing js feature. We'd basically create a shim crate that re-exports getrandom, and depend on that in wasm32-unknown-unknown when some rng-getrandom feature of uuid is enabled.