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
