bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

[Bruno Haible <bruno@clisp.org>]

Paul Eggert wrote:
> Thanks for the detailed diagnosis, Bruno. To try to fix the problems I 
> installed the attached patches into Gnulib.

These look all good. Here's again my evaluation of the three scenarios:

(Q1) What is the expected quality inside a single gen_tempname call?

It depends on quality of random_bits(). Usually on the quality of
getrandom(), which is good on most systems. And for the other systems,
the "ersatz" in random_bits() gives reasonable quality.

(Q2) What is the expected quality of multiple gen_tempname calls in a
     single process?
(Q3) What is the expected quality when considering different processes
     that call gen_tempname?

Both have the same answer: The file name essentially depends on the
first call to random_bits(). Two different calls to random_bits()
can be correlated only if
  - getrandom() is not well supported, and
  - CLOCK_REALTIME is not defined, and
  - we're in the same process, less than 0.01 sec apart.
IMO, that's good enough.

> If I understand things 
> correctly, these patches should fix the 0.1% failure rate you observed 
> on 64-bit mingw.

Yes. Running the "case 2" part 1000 times again, among the 2000 generated
file names, there are no duplicates — neither on 32-bit mingw, nor on 64-bit
mingw.

> They also fix a minor security leak I discovered: in 
> rare cases, ASLR entropy was used to generate publicly visible file 
> names, which is a no-no as that might help an attacker infer the 
> randomized layout of a victim process.

Excellent observation :-)

> These fixes follow some but not all the suggestions you made. The basic 
> problem I saw was that tempname.c was using too much belt-and-suspenders 
> code, so much so that the combination of belts and suspenders 
> misbehaved. I simplified it a bit and this removed the need for some of 
> the suggestions.

Thanks. The major quality boost comes from invoking getrandom() always.

Bruno