From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: OpenSSL randomness seeding |
Date: | 2020-07-21 19:44:58 |
Message-ID: | D05277F7-89C8-42DD-BEB6-CA40A7ACE8D3@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 21 Jul 2020, at 17:31, David Steele <david(at)pgmasters(dot)net> wrote:
> On 7/21/20 8:13 AM, Daniel Gustafsson wrote:
>> Another thing that stood out when reviewing this code is that we optimize for
>> RAND_poll failing in pg_strong_random, when we already have RAND_status
>> checking for a sufficiently seeded RNG for us. ISTM that we can simplify the
>> code by letting RAND_status do the work as per 0002, and also (while unlikely)
>> survive any transient failures in RAND_poll by allowing all the retries we've
>> defined for the loop.
>
> I wonder how effective the retries are going to be if they happen immediately. However, most of the code paths I followed ended in a hard error when pg_strong_random() failed so it may not hurt to try. I just worry that some caller is depending on a faster failure here.
There is that, but I'm not convinced that relying on specific timing for
anything RNG or similarly cryptographic-related is especially sane.
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2020-07-21 19:57:57 | Re: v13 planner ERROR: could not determine which collation to use for string comparison |
Previous Message | David G. Johnston | 2020-07-21 19:34:01 | Re: v13 planner ERROR: could not determine which collation to use for string comparison |