> On 5 Nov 2020, at 04:44, Michael Paquier <mich...@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
