On 09/08/2014 07:13 PM, Thorsten Glaser wrote:
Lorenzo Beretta dixit:
The $RANDOM variable should not be exported: it's useless, and it may
fool scripts that try to detect if the shell provides it.
This is an upstream decision, please continue this either on
the mailing list (Cc’d) or (if you really must) the Launchpad
tracker.
Actually, this is not useless: it’s imported into subshells,
and mksh reads the environment at startup and lets it contribute
to entropy there. The absence of proper arc4random() in most
operating systems is really a PITA.
I read mksh(1), it says RANDOM comes from an lcg, rnd_get() agrees, that
seemed enough fact checking when I reported the bug :)
On closer reading I see what you mean - I assumed that setting eg
RANDOM=1 would simply seed the rng, like bash&zsh; instead you're mixing
the value provided by $RANDOM in the current state together with other
stuff.
I was wondering if there would be any trouble replacing the lcg with a
generator whose state is __made__ of n>1 words - something like, off the
top of my head, xor128, JKISS, you name it.
The disadvantage is that both have some bad seeds (easy to reject);
the advantage is that seeding becomes much easier, rather than spending
tens of lines in var.c and main.c you can use pid, ppid, gettimeofday
etc directly to set the state with hardly any need for hashing and only
a negligible chance to be anywhere close to some other seed.
Just to be extra clear, it's not "replacing" as in "hey, I have an idea,
write it - that's what I'm NOT paying you for"; it's replacing as in
"any objections? ok to discuss it? I'll write a patch if you think it
would be nice but you're not overly interested".
Btw, agreed, arc4random should be everywhere.
We might throw it away (and just use arc4random() if there,
and… whatever… if not), for the sake of simplicity. But then,
lesser platforms (such as GNU/Linux) would have worse entropy
in $RANDOM values.
That being said, there is a Pure mksh™ implementation of
arc4random() around… only downside is, it reads a lot of
bytes from /dev/urandom, which kills Linux’ inferiour kernel
RNG as well…
Funny, I solved the same problem reimplementing rand() in terms of
urandom and (ab)using LD_PRELOAD; it works, but it's ugly.
I didn't know urandom in linux had these kind of problems, but modern
arc4random uses chacha20, which only requires 16/32 bytes for its keys.
I wish we had access to AT_RANDOM, but glibc uses all of
it for its own purposes instead of setting up an SRNG¹…
Anyway, I do not discuss upstream things like this in the
Debian bugtracker, as this is most definitely not a bug
in the package.
You're totally right, sending emails is too easy - sorry :)
bye,
//mirabilos
① stretching RNG
