Re: Move OpenSSL random under USE_OPENSSL_RANDOM

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: Magnus Hagander <magnus@hagander.net>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-05T09:49:45Z
Lists: pgsql-hackers
> On 5 Nov 2020, at 04:44, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Wed, Nov 04, 2020 at 10:05:48AM +0100, Magnus Hagander wrote:
>> Yes, we should absolutely do that. We already do this for
>> pg_strong_random() itself, and we should definitely repeat the pattern
>> in the init function.
> 
> This poked at my curiosity, so I looked at it.  The result looks
> indeed like an improvement to me, while taking care of the point of
> upthread to make the implementation stuff controlled only by
> USE_OPENSSL_RANDOM.  Per se the attached.

This must check for USE_OPENSSL as well as per my original patch, since we'd
otherwise fail to perform post-fork initialization in case one use OpenSSL with
anothe PRNG for pg_strong_random.  That might be theoretical at this point, but
if we ever support that and miss updating this it would be problematic.

+#if defined(USE_OPENSSL_RANDOM)

I'm not sure this comment adds any value, we currently have two non-TLS library
PRNGs in pg_strong_random, so even if we add NSS it will at best be 50%:

+ * Note that this applies normally to SSL implementations, so when
+ * implementing a new one, be careful to consider this initialization
+ * step.

> This could make random number generation predictible when an extension
> calls directly RAND_bytes() if USE_OPENSSL_RANDOM is not used while
> building with OpenSSL, but perhaps I am just too much of a pessimistic
> nature.

Any extension blindly calling RAND_bytes and expecting there to automagically
be an OpenSSL library available seems questionable.

cheers ./daniel


Commits

  1. Remove ability to independently select random number generator

  2. Add pg_strong_random_init function to initialize random number generator