-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use getrandom, simplify OsRng, deprecate EntropyRng #765
Conversation
@newpavlov the test fails on #[cfg(any(
feature = "std",
windows, unix,
target_os = "redox",
target_arch = "wasm32",
))]
mod error_impls; This is not the usual |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Though I think we should follow the approach with optional dependency of rand_core
on getrandom
.
wasm-bindgen = ["rand_os/wasm-bindgen"] | ||
stdweb = ["rand_os/stdweb"] | ||
wasm-bindgen = ["getrandom/wasm-bindgen"] | ||
stdweb = ["getrandom/stdweb"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do if we don't want to make a breaking change — though we can't ever lose these without a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
if dest.len() == 0 { return Ok(()); } | ||
|
||
getrandom(dest).map_err(|e| | ||
Error::with_cause(ErrorKind::Unavailable, "OsRng failed", e)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I thought the old error will be replaced with getrandom::Error
, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, yes, but not as part of this PR, hence I hacked in a map for now.
Would you like to look into this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I can do it a bit later.
src/rngs/os.rs
Outdated
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(()); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a test for 0-byte reads to getrandom
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a test for 0-byte reads to getrandom?
Yes, I think we should.
Ok(()) | ||
|
||
getrandom(dest).map_err(|e| | ||
Error::with_cause(ErrorKind::Unavailable, "OsRng failed", e)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See rand::OsRng
comments.
Hm, I thought that I will send a PR with the fix. UPD: Ups, I've accidentally commited the fix directly instead of creating a PR. |
@@ -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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to deprecate this trait as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is the question from the top comment (whoops, → EntropyRng
FromEntropy
).
Hah, okay. |
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.
Okay, I rewrote the I also pushed a hack to pull |
Fix rand_os example
Hopefully this is good to go now (not all questions resolved, but follow-up PRs allowed). |
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 torand_jitter
is easy enough for those people.This does not deprecate
FromEntropy
, which is simply sugar forfrom_rng(OsRng).unwrap()
. This trait already has some usage. We could move the method toSeedableRng
but this requires dependence ongetrandom
fromrand_core
; I'm not sure if it is justified.Review @newpavlov?