On Mon, Dec 3, 2018 at 9:18 PM Chet Ramey <chet.ra...@case.edu> wrote: > On 12/3/18 11:31 AM, Ole Tange wrote: > > 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.
I would think that a major release would be the perfect opportunity to change this: Major releases in general are known for not being 100% compatible with earlier releases. > > 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. > > This is always requirements-driven. Nobody expects to get cryptographic- > quality PRNGs out of the shell (or any of the libc interfaces, tbh), While I did not *expect* it, I honestly had hoped for it. Otherwise I would never have raised this. I feel a bit as if I am saying: "Hey this using environment variables to store function definitions seems like it could be a problem, but I do not have an exploit. I do, however, have an easy fix so that it will not be a problem in the future." And you replying: "Come back when you have an exploit." And then we simply wait for Shellshock to happen. > that's never been promised or expected. You can't really expect that from > something that only promises 16 bits. The naive user may assume that he can simply concatenate values and get 128 bits: echo $RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM-$RANDOM But I hope we agree that he will not get 128 bits of randomness no matter how many values he concatenates. Or he might expect that this is not an infinite loop: while [ ! $RANDOM = $RANDOM ] ; do true; done just like this is not: while [ ! $RANDOM = $(( 1+$RANDOM )) ] ; do true; done (This one came as a surprise to me - I had totally expected $RANDOM would give the same value twice 1 time in 65536 tries on average. Tested on 4.4.19) At the very least make it clear from the documentation what $RANDOM can be used for. 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 without giving him even a hint about this. > However, for common scripting tasks like generating temporary filenames, > it's perfectly adequate. I hope that we agree that you should never use $RANDOM for generating temporary file names in a dir that an attacker has write access to. mktemp is made to do that in a secure fashion. But your comment actually emphasizes my point: We _will_ have users who are naive enough to use $RANDOM in ways you and I would not do, because we know it is unsafe. Let's make those usages a little safer. /Ole
