On Mon, Dec 3, 2018 at 3:56 PM Chet Ramey <chet.ra...@case.edu> wrote:
> There has to be a compelling reason to change this, especially at a point > so close to a major release. The reason for my submission was that I needed a bunch of random numbers in a shell script, but I needed them to be high quality. Luckily I did not just assume that Bash delivers high quality random numbers, but I read the source code, and then found that the quality was low. I do not think must users would do that. The man page does not warn about the low quality either, and it does not point to a way to get high quality numbers. Somehow we expect the user to simply know this. So from personal experience I have wasted a few hours on that account. Had I simply assumed the numbers were high quality, it might have caused problems for me at a later stage. And it is protect users who do not read the man page and source code that I suggest the change. > You might be expecting too much from bash's random number generator. Is > the problem that its period is at most 2**16? For its intended uses, the > cycle length is acceptable. Do you disagree? If I read the man page, I do not see what the intended use is. Where is that documented? If the user's view on the intended use differs from the developers', then there is a risk of misaligned expectations. Documenting the developers' view is IMHO a poor way of mitigating this, if there is a simple solution that will satisfy the demanding user. I see software daily that is being use in ways it was not intended. Usually it does not break, and for GNU tools this (in my experience) is especially true, because the GNU project officially endorses writing robust programs. So my suggestion is really just to be proactive, so that when users do not use it in the intended way, it will still not break. If you choose not to implement a CSPRNG, then please at least make it clear in the man page that $RANDOM is a poor RNG, and what the intended use is. /Ole