-
Notifications
You must be signed in to change notification settings - Fork 13k
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
rand: Fix OsRng::fill_bytes on Windows #31876
Conversation
…indows CryptGenRandom takes a DWORD (u32) for the length so it only supports writing u32::MAX bytes at a time. Casting the length from a usize caused truncation meaning the whole buffer was not always filled.
@bors r+ Look like a security bug cc @rust-lang/core |
📌 Commit ac3cc33 has been approved by |
it is a security bug, but note that what really matters is the external crate, not this one. rust-random/rand#99 |
⌛ Testing commit ac3cc33 with merge 4236392... |
💔 Test failed - auto-mac-32-opt |
@bors: retry On Fri, Feb 26, 2016 at 11:22 AM, bors notifications@github.com wrote:
|
CryptGenRandom takes a DWORD (u32) for the length so it only supports writing u32::MAX bytes at a time. Casting the length from a usize caused truncation meaning the whole buffer was not always filled. cc #31841 This is the same as rust-random/rand#99. I think it's a good idea to keep the implementations in sync. r? @alexcrichton
CryptGenRandom takes a DWORD (u32) for the length so it only supports
writing u32::MAX bytes at a time.
Casting the length from a usize caused truncation meaning the whole
buffer was not always filled.
cc #31841
This is the same as rust-random/rand#99. I think it's a good idea to keep the implementations in sync.
r? @alexcrichton