briansmith
update getrandom
please update getrandom.
The version of getrandom has been updated. Until now, if you want to compile for wasm,
getrandom = { version = "0.2", features = ["std", "js"] }
getrandom = { version = "0.3.1", features = ["std", "wasm_js"] }
I had written code like this, but it causes problems because the version of getrandom on which this library depends is out of date.
Related issues, etc. https://github.com/briansmith/ring/pull/2218 https://github.com/briansmith/ring/pull/2130 https://github.com/briansmith/ring/issues/2187
https://rust-random.github.io/book/update-0.9.html https://github.com/rust-random/rand/blob/master/CHANGELOG.md
It will be a while before I can review the changes between the last time I looked at getrandom and the getrandom 0.3 release. Don't hold your breath.
https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md
The changes that may be relevant are ・Rename getrandom and getrandom_uninit functions to fill and fill_uninit respectively ・js features to wasm_js
Thanks. AFAICT getrandom 0.3 changes the way configuration is done in a way that is difficult for ring to adjust to, or at least I am not sure how to adjust ring to use the new configuration mechanism.
Plus, I review every commit in getrandom before I upgrade to a new version. At one point last year I was reviewing getrandom commits in real time, but I haven't reviewed them for a while. So I have about a year of getrandom commits to review 1-by-1 before I can do the update.
My current perspective is that it is annoying to others to be depending on getrandom 0.2 when getrandom 0.3 is available, so it is worth somebody trying to resolve things. I don't want to break backward compatibility with 0.17 in the next few months, so such a change would need to be backward compatible. I am open to hearing creative solutions.
How about switching using features?
In Cargo.toml, you can write it like this:
_getrandom_alias_3 = { version = "0.3.1", package = "getrandom", features = [
"std",
"wasm_js",
] }
_getrandom_alias_2 = { version = "0.2", package = "getrandom", features = [
"std",
"js",
] }
This allows you to include multiple versions as dependencies. Ideally, you should update the library version instead, so this is not the best approach.
If anyone reading absolutely needs a temp solution to get ring using getrandom 0.3, then clone the repo, and change the very bottom of src/rand.rs to:
fn fill_impl(&self, dest: &mut [u8]) -> Result<(), error::Unspecified> {
getrandom::fill(dest).map_err(|_| error::Unspecified)
}
And ring's root Cargo.toml to say
getrandom = { version = "0.3.2" }, instead of 0.2.10
Then use the crate patch feature in your project's root Cargo.toml:
[patch.crates-io]
ring = { path = "ring" }
May not work for everyone's use case, but it works for me at least
@briansmith
I don't want to break backward compatibility with 0.17 in the next few months
How about now? 🤔
I haven't completed the review of getrandom 0.3 yet. Currently we can't use getrandom 0.3 for wasm32-unknown-unknown because getrandom 0.3 doesn't provide a way for our wasm32_unknown_unknown_js feature to work. I'm not interested in debating whether it is wrong for ring to have its wasm32_unknown_unknown_js feature; it has it.
If I were to release a 0.18 with breaking changes, I would do so in a way where I could release a new 0.17 release that is implemented in terms of 0.18, which means the problem would remain. I foresee 0.17 living for a long time.
One solution would be to vendor the getrandom 0.3 wasm_js.rs backend code, and use the vendored code if and only if wasm32_unknown_unknown_js feature is enabled and the getrandom_backend cfg directive isn't set; otherwise use getrandom 0.3. My understanding is that cfg directives are global so ring should be able to see this even though the directive isn't intended for ring. We could implement this in steps:
First PR: Vendor the getrandom wasm_js.rs backend along with wrappers in lib.rs into rand/getrandom/{lib.rs,backends.rs,wasm_js.rs}. Compile and use the vendored implementation only if the target is wasm32 and wasm32_unknown_unknown_js is enabled. Use getrandom 0.3 otherwise.
Second PR: Avoid compiling and using the vendored implementation if the getrandom_backend cfg is set.
Third PR: Ignore the wasm32_unknown_unknown_js feature flag and document that it is deprecated. Document that on wasm32-unknown-unknown we will use the wasm_js backend if and only if getrandom_backend is not set; otherwise, we will use getrandom.
I don't intend to work on this myself but I would accept a PR that implements "First PR" above.
The workaround above is basically what the uuid crate did: https://github.com/uuid-rs/uuid/pull/793, https://github.com/uuid-rs/uuid/pull/794, https://github.com/uuid-rs/uuid/pull/804, though I think looking at cfg(getrandom_backend) would have been a better choice for them.
Just as tracking, I've tried to implement the "first PR" mentioned above in #2700.
