proposal: Go 2: move math/rand to x/math/rand

[adamdecaf]

math/rand has several known and documented problems (see #21835) and it's easily mistaken for crypto/rand (see #20661). This is a proposal to move it out of the standard library, which would give several advantages.

• Easier ability to implement other sources and tweak it's performance or space usage
• Removal accidental use (when developer should have used crypto/rand)

The go fix tool could rewrite imports to x/math/rand or default to crypto/rand. There are real use cases for a deterministic generator (jitter, tests, etc) so we shouldn't remove it entirely. We should gather uses of math/rand that crypto/rand doesn't satisfy.

[ianlancetaylor]

Are you suggesting that for Go 2 we not implement #21835, and instead move math/rand out of the standard library? Or do you think it would be OK to adopt #21835 for Go 2?

[ALTree]

Easier ability to implement other sources and tweak it's performance or space usage

This same argument applies to literally every other package in the standard library; and yet you need to have something in it, right? : ) Unless go2 goes in the "move everything outside of the main repository" direction, I don't see how it could be reasonable to move a fundamental package like the one that generates random numbers out of stdlib, while still having a lot of other much less fundamental packages in it.

While it's true that we have been bitten in the past by the impossibility to fix fundamental deficiencies in the package's underling randomness source without breaking retro-compatibility, a new, clean implementation that fixes the most glaring issues with the package, like Rob proposed in #21835, could very well fit into the go2 standard library.

Removal accidental use (when developer should have used crypto/rand)

There's a (very prominent) warning at the top of the doc, in the package overview, about this:

For random numbers suitable for security-sensitive work, see the crypto/rand package.

And frankly, I doubt that a user that doesn't understand the difference between secure and non-secure random number generation will be able to write a cryptographically-secure application, even if we move math/rand outside the standard library.

[adamdecaf]

@ianlancetaylor I have no problems with implementing #21835 in Go 2.

@ALTree I agree with you, but why does the stdlib even need to offer two random number generators? Do users care?

I (want to) assume anyone really needing math/rand over crypto/rand can find and use it from x/math/rand, but that the stdlib default is usable (and secure) for most uses.

[ianlancetaylor]

Thanks. I'm going to close this issue in favor of #21835.

Discussions of why we need both math/rand and crypto/rand are perhaps best held on golang-dev.