Use getrandom, simplify OsRng, deprecate EntropyRng by dhardy · Pull Request #765 · rust-random/rand

dhardy · 2019-04-02T13:07:32Z

Implements #760

This implements several of the mentioned changes. In theory the re-implementation of OsRng can be omitted but I think for most users this will decrease the number of crates required with very little issue; if necessary we can revert this easily later.

This also removes the re-export of JitterRng which is a breaking change. I do not think this will impact many users, and switching to rand_jitter is easy enough for those people.

This does not deprecate FromEntropy, which is simply sugar for from_rng(OsRng).unwrap(). This trait already has some usage. We could move the method to SeedableRng but this requires dependence on getrandom from rand_core; I'm not sure if it is justified.

Review @newpavlov?

dhardy · 2019-04-02T16:49:45Z

@newpavlov the test fails on cloudabi because of this rule in getrandom:

#[cfg(any(
    feature = "std",
    windows, unix,
    target_os = "redox",
    target_arch = "wasm32",
))]
mod error_impls;

This is not the usual no_std support approach, though since we don't have an env var or build-wide cfg item it does make some sense to "guess" whether we're using std. But we still have a std feature; shouldn't we choose one option or the other? Otherwise we see things like this: std support works on common platforms, but fails unexpectedly when testing on other platforms.

newpavlov

Looks good! Though I think we should follow the approach with optional dependency of rand_core on getrandom.

newpavlov · 2019-04-02T17:01:56Z

Cargo.toml

-wasm-bindgen = ["rand_os/wasm-bindgen"]
-stdweb = ["rand_os/stdweb"]
+wasm-bindgen = ["getrandom/wasm-bindgen"]
+stdweb = ["getrandom/stdweb"]


I am not sure if we need to bubble these features. Users can write in application crates getrandom = { version = "*", features = [ .. ] }. Something similar will have to be done if rand is used indirectly via dependencies, which I think will be fairly common.

We do if we don't want to make a breaking change — though we can't ever lose these without a breaking change.

Well, v0.7 is already a breaking release, so we could use this chance to cleanup those features. Though if you want to keep number of breaking changes to a minimum, then it's fine to keep it as-is.

On second thoughts, no, lets keep the feature forwarding. It's convenient for use in our tests and something we might have some other reason to break in the future (hopefully eventually these features won't be needed), so there's not much sense in a breaking change to achieve so little.

src/lib.rs

src/rngs/os.rs

newpavlov · 2019-04-02T17:08:12Z

src/rngs/os.rs

+        if dest.len() == 0 { return Ok(()); }
+
+        getrandom(dest).map_err(|e|
+            Error::with_cause(ErrorKind::Unavailable, "OsRng failed", e))


Hm, I thought the old error will be replaced with getrandom::Error, no?

Possibly, yes, but not as part of this PR, hence I hacked in a map for now.

Would you like to look into this?

Yeah, I can do it a bit later.

newpavlov · 2019-04-02T17:11:22Z

src/rngs/os.rs

+    fn try_fill_bytes(&mut self, dest: &mut [u8]) -> Result<(), Error> {
+        // Some systems do not support reading 0 random bytes.
+        // (And why waste a system call?)
+        if dest.len() == 0 { return Ok(()); }


I think this branching should be removed as it does not follow the principle of least astonishment. Systems which do not support reading 0 bytes should be handled on getrandom level. Let's say someone will want to first check if OsRng works, why force user to use 1 byte array?

True, this should be done as part of getrandom if at all. I don't agree that retrieving 0 bytes can be considered a test of readiness however (precisely because this kind of code may exist).

Should we add a test for 0-byte reads to getrandom?

Should we add a test for 0-byte reads to getrandom?

Yes, I think we should.

newpavlov · 2019-04-02T17:12:42Z

rand_os/src/lib.rs

-        Ok(())
+
+        getrandom(dest).map_err(|e|
+            Error::with_cause(ErrorKind::Unavailable, "OsRng failed", e))


See rand::OsRng comments.

newpavlov · 2019-04-02T17:15:13Z

Hm, I thought that cloudabi is considered unix. Worth to create rust-lang/rust issue? Ideally I would like to automatically enable std feature for std-capable target, but unfortunately AFAIK cargo does not provide the required functionality.

I will send a PR with the fix.

UPD: Ups, I've accidentally commited the fix directly instead of creating a PR.

src/rngs/os.rs

vks · 2019-04-03T05:57:28Z

src/lib.rs

@@ -480,35 +479,16 @@ impl_as_byte_slice_arrays!(!div 4096, N,N,N,N,N,N,N,);
 /// [`OsRng`]: rngs::OsRng
 #[cfg(feature="std")]
 pub trait FromEntropy: SeedableRng {


Do we want to deprecate this trait as well?

That is the question from the top comment (whoops, ~~EntropyRng~~ → FromEntropy).

dhardy · 2019-04-03T14:16:48Z

UPD: Ups, I've accidentally commited the fix directly instead of creating a PR.

Hah, okay. ~~Lets remove the WASM-feature forwarding as suggested and re-run the tests.~~ Rebased.

This is controversial: a small amount of code redundancy to avoid an extra import.

This is a breaking change for anyone using rngs::JitterRng; such users should switch to rand_jitter::JitterRng.

src/rngs/os.rs

dhardy · 2019-04-04T09:51:29Z

Okay, I rewrote the rngs module documentation completely (a little shorter and hopefully clearer), as well as adding the requested usage example.

I also pushed a hack to pull getrandom from master, to test @newpavlov's fix.

Fix rand_os example

dhardy · 2019-04-05T15:29:51Z

Hopefully this is good to go now (not all questions resolved, but follow-up PRs allowed).

newpavlov reviewed Apr 2, 2019

View reviewed changes

vks reviewed Apr 3, 2019

View reviewed changes

src/rngs/os.rs Outdated Show resolved Hide resolved

vks reviewed Apr 3, 2019

View reviewed changes

dhardy mentioned this pull request Apr 3, 2019

New rand_distr crate #761

Merged

dhardy added 5 commits April 3, 2019 15:23

Replace rand_os implementation with shim around getrandom

1976a7f

Re-implement OsRng in Rand

23e1f04

This is controversial: a small amount of code redundancy to avoid an extra import.

Simplify and deprecate EntropyRng

8cfe210

Remove dependence on rand_jitter

b231ac2

This is a breaking change for anyone using rngs::JitterRng; such users should switch to rand_jitter::JitterRng.

Review fixes

23fc4a1

dhardy force-pushed the entropy branch from d0feb11 to 23fc4a1 Compare April 3, 2019 14:23

newpavlov reviewed Apr 3, 2019

View reviewed changes

src/rngs/os.rs Show resolved Hide resolved

dhardy added 2 commits April 4, 2019 11:56

Re-write rngs module documentation

8fa74fc

Add OsRng examples

57fbc71

Fix rand_os example

dhardy force-pushed the entropy branch from 5963aa5 to 7b4e7c6 Compare April 4, 2019 10:57

Bump version requirement on getrandom to 0.1.1

b83a4c5

dhardy force-pushed the entropy branch from 7b4e7c6 to b83a4c5 Compare April 5, 2019 15:28

Implement Default for OsRng

f84dccb

dhardy merged commit 2abc78a into rust-random:master Apr 6, 2019

dhardy deleted the entropy branch April 9, 2019 13:05

dhardy mentioned this pull request Apr 10, 2019

getrandom, security and fallback entropy #760

Closed

ordian mentioned this pull request May 5, 2019

Use EntropyRng instead of OsRng paritytech/parity-common#130

Merged

dhardy mentioned this pull request May 15, 2019

Tracker: Rand 0.7 #715

Closed

22 tasks

dependabot bot mentioned this pull request Mar 15, 2021

Update rand requirement from 0.7 to 0.8 transparencies/yew#5

Open

Uh oh!

Conversation

dhardy commented Apr 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dhardy commented Apr 2, 2019

Uh oh!

newpavlov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

newpavlov commented Apr 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhardy commented Apr 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

dhardy commented Apr 4, 2019

Uh oh!

dhardy commented Apr 5, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

dhardy commented Apr 2, 2019 •

edited

Loading

newpavlov commented Apr 2, 2019 •

edited

Loading

dhardy commented Apr 3, 2019 •

edited

Loading