Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
От | Michael Paquier |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |
Дата | |
Msg-id | CAB7nPqQq-1km3vnMJd5gNoYJ9pnCLDqZimajWBxFh24pduwPsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Oct 18, 2016 at 12:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paquier@gmail.com> writes: >> And actually, enabling prngd would need to be controlled by a >> configure switch as well disabled by default, no? > > AFAICT, openssl has no configuration options related to prngd; they > seem to be able to use it automatically when /dev/[u]random isn't there. > This surprises me a bit because the location of prngd's random-data socket > is evidently variable. I've not dug into exactly how openssl figures that > out, but I'm sure a little quality time with the openssl sources would > explain it. I dug a bit into the code around RAND_egd and how it gets into fetching a method to get random bytes but got tired of the game for now. The man page means visibly that OpenSSL connects directly to the daemon: https://www.openssl.org/docs/manmaster/crypto/RAND_egd.html By the way, after a short chat with Heikki, we can up with an extra idea: resurrect unix_std from pgcrypto in pg_strong_random as the last fallback method and instead of using sha1, use sha2 as SCRAM is going to need those functions in src/common/ as well. Having a configure switch to enable it may be a good idea. -- Michael
В списке pgsql-hackers по дате отправления: