-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
crypto: make pseudoRandomBytes an alias for randomBytes #557
Conversation
} else { | ||
r = RAND_bytes(reinterpret_cast<unsigned char*>(req->data()), req->size()); | ||
} | ||
r = RAND_bytes(reinterpret_cast<unsigned char*>(req->data()), req->size()); |
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.
Maybe make this const int r = ...
.
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.
updated
LGTM but I would like @indutny to sign off on it as well. |
4fdfcb2
to
a120e87
Compare
ok moved the declaration down and made it a const, then split the line so it would pass linting, should an update to the docs be part of the same pull or a separate one? |
} else { | ||
r = RAND_bytes(reinterpret_cast<unsigned char*>(req->data()), req->size()); | ||
} | ||
const int r = RAND_bytes(reinterpret_cast<unsigned char*>(req->data()), |
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.
Please don't hate me but it's > 80 columns now.
EDIT: Preempted!
Please roll it into this one. |
@bnoordhuis perhaps we should not block in case of pseudo random bytes? |
Otherwise I suggest deprecating |
I don't think this PR changes that. Or does it?
I agree but I would suggest doing that in a separate PR, provided we agree this PR is not a functional change. That way, we can land this PR now and land the deprecation PR in 1.1.0. |
@bnoordhuis this should not be a functional change @indutny maybe a the blocking/not blocking distinction can be rolled into the changes to the api around randomBytesSync. Will update the docs |
Previously pseudoRandomBytes worked similarly to randomBytes but in the event of insufficient entropy would silently return non-secure values. As of f68a116 the entropy pool blocks if there is insufficient entropy instead of giving an error so there is now no longer a case where pseudoRandomBytes would act differently then randomBytes. Docs are updated to remove pseudoRandomBytes and to clarify that randomBytes now does block instead of erring when entropy is low.
updated |
LGTM, let's deprecate it soon. |
Previously pseudoRandomBytes worked similarly to randomBytes but in the event of insufficient entropy would silently return non-secure values. As of f68a116, the entropy pool blocks if there is insufficient entropy instead of giving an error so there is now no longer a case where pseudoRandomBytes would act differently than randomBytes. Docs are updated to remove pseudoRandomBytes and to clarify that randomBytes now does block instead of erring when entropy is low. PR-URL: #557 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>
Landed with some touch-ups in e5e5980. Thanks, Calvin! |
Previously pseudoRandomBytes worked similarly to randomBytes but in the event of
insufficient entropy would silently return non-secure values. As of f68a116
the entropy pool blocks if there is insufficient entropy instead of giving an
error so there is now no longer a case where pseudoRandomBytes would act
differently then randomBytes.
Inspired by discussions on #545