Skip to content
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

Jump to bottom

crypto/rand: Documentation for errors #54980

Open
Deleplace opened this issue Sep 9, 2022 · 4 comments
Open

crypto/rand: Documentation for errors #54980

Deleplace opened this issue Sep 9, 2022 · 4 comments
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@Deleplace
Copy link
Contributor

The 3 exported funcs Int, Prime, Read return an error, but the current documentation doesn't say why and when errors might occur. Also their is no guidance about how to deal with a non-nil error: would a caller-side retry policy make sense?

I suggest we write a short explanation about why errors are part of the API at all, what such errors would look like, and how to deal with them.
@Deleplace Deleplace mentioned this issue Sep 9, 2022
Closed
@mknyszek mknyszek added this to the Backlog milestone Sep 9, 2022
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 9, 2022
@mknyszek
Copy link
Contributor

mknyszek commented Sep 9, 2022

CC @golang/security

@Deleplace
Copy link
Contributor Author

Prime does mention that its errors comes from rand.Read.

It may be confusing to figure out if we're likely to have errors "because CSPRNGs inherently use system calls that may fail", or "because we're accepting any custom io.Reader in Int and Prime", or if "Reader cannot return errors, but we still want to stick to the io.Reader interface".

@ericlagergren
Copy link
Contributor

would a caller-side retry policy make sense?

In general, there is no safe non-nil error result from rand.Reader or rand.Read.

@bwesterb
Copy link

I would be in favour of having crypto/rand.[Reader.]Read never return an error, and completely fill the provided slice. (And have it panic if the underlying system call errors.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@bwesterb @mknyszek @ericlagergren @gopherbot @Deleplace