From: | David CARLIER <devnexen(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] using arc4random for strong randomness matters. |
Date: | 2017-11-22 18:47:19 |
Message-ID: | CA+XhMqw3ai=eM3AJRyUVNa7w6UORKwb2Er9Ab=MKQy0QCdgR5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I dunno, it seems like this is opening us to a new set of portability
> hazards (ie, sub-par implementations of arc4random) with not much gain to
> show for it.
>
Hence I reduced to three platforms only.
>
> IIUC, what this code actually does is reseed itself from /dev/urandom
> every so often and work from a PRNG in between. That's not a layer that
> we need, because the code on top is already designed to cope with the
> foibles of /dev/urandom --- or, to the extent it isn't, that's something
> we have to fix anyway. So it seems like having this optionally in place
> just reduces what we can assume about the randomness properties of
> pg_strong_random output, which doesn't seem like a good idea.
>
> That I admit these are valid points.
Cheers.
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Pedersen | 2017-11-22 18:56:06 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | Pavel Stehule | 2017-11-22 18:46:12 | Re: [HACKERS] SQL procedures |