Cleaning up crate features

[KodrAus]

This is a meta issue to take a fresh look at the library’s dependency tree. In particular:

• rng support: we have a fast-rng feature that adds rand as a dependency because getrandom is slow on Windows. Is that still necessary?
• js: we pull in wasm-bindgen and getrandom unconditionally when building for the web. Could we use our crate features more cleverly to only pull in features we need?
• macros: we have a macro-diagnostics feature that enables a proc-macro for better error reporting of compile-time UUID literals. Is this actually used? Can we emit more meaningful errors without needing a proc-macro on more recent compilers?

We can consider a major 2.x version of uuid that is semver-compatible with 1.x (no actual API changes and re-export 2.x in 1.x), but that removes or rejigs our crate features as necessary to keep our dependency tree sane.

[TylerBloom]

js: we pull in wasm-bindgen and getrandom unconditionally when building for the web. Could we use our crate features more cleverly to only pull in features we need?

From my understanding, you only need the js when you are compiling to WASM and need the rnd feature. (You might need it for atomics too, but the following still holds with a few additions). So, we can change the definition of the rnd feature to be: rnd = ["wasm-bindgen", "getrandom"]. Then, the dependencies imports can be gated by target:

rnd = ["wasm-bindgen", "getrandom"]

[dependencies]
getrandom = { version = "0.2" }

[target.'cfg(target_arch = "wasm32")'.dependencies]
getrandom = { version = "0.2", features = ["js"], optional = true }
wasm-bindgen = { version = "0.2", optional = true }

This also makes the js feature obsolete.

[KodrAus]

That's interesting 🤔 Would that rnd feature simply ignore the wasm-bindgen and getrandom features on targets that don't specify them as dependencies?

[TylerBloom]

That's interesting 🤔 Would that rnd feature simply ignore the wasm-bindgen and getrandom features on targets that don't specify them as dependencies?

Ya, that's correct. I don't know how this applies to user-selected features (i.e. features that you specify via cargo's --feature flag), but, for features that enable other features, cargo doesn't care. That or cargo is aware that wasm-bindgen is a valid feature sometimes, so if it gets specified and is not used that's ok.

[roderickvd]

For fast-rng with rand you would want to use SmallRng but we can do better: use fastrand instead. It's considerably lighter-weight than rand. I can put in a PR.

[vks]

For fast-rng with rand you would want to use SmallRng but we can do better: use fastrand instead. It's considerably lighter-weight than rand. I can put in a PR.

I don't think this is a good idea. SmallRng and fastrand use predictable RNGs, which means any UUID generated by them would be predictable. This can result in security issues for some UUID v4 applications.

[roderickvd]

PR was already closed, so not pursuing it anymore.

[marcomq]

I don't think this is a good idea. SmallRng and fastrand use predictable RNGs, which means any UUID generated by them would be predictable. This can result in security issues for some UUID v4 applications.

Couldn't it be an issue when using fast-rng just for some local high-throughput location? When using fast-rng as feature, you might use it everywhere by accident. It might even be injected into another authentication crate you are using that is using uuid-v4 for token generation. And then, this authentication crate would also generate uuid-v4 tokens with fast-rng as the uuid version might fit and features are just considered optional and non destructive.

Wouldn't it be better to have explicit fast versions as separate function, separate module or maybe even separate crate?
I just created an own fast-uuid-v7 crate because I didn't knew fast-rng existed. But I probably would also avoid such a feature for security reasons.

[KodrAus]

@marcomq We wouldn't make the source of the fast-rng feature any less secure than the default. It's a feature that's mostly only useful on Windows, but may not even be necessary there anymore now that getrandom appears to be using a different underlying Windows API.