On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > > On 26 Aug 2020, at 09:56, Michael Paquier <mich...@paquier.xyz> wrote: > > On Tue, Aug 25, 2020 at 03:52:14PM +0200, Daniel Gustafsson wrote: > > >> The attached moves all invocations under the correct guards. RAND_poll() > >> in > >> fork_process.c needs to happen for both OpenSSL and OpenSSL random, thus > >> the > >> check for both. > > > > Yeah, it could be possible that somebody still calls RAND_bytes() or > > similar without going through pg_strong_random(), so we still need to > > use USE_OPENSSL after forking. Per this argument, I am not sure I see > > the point of the change in fork_process.c as it seems to me that > > USE_OPENSSL_RANDOM should only be tied to pg_strong_random.c, and > > you'd still get a compilation failure if trying to use > > USE_OPENSSL_RANDOM without --with-openssl. > > That's certainly true. The intention though is to make the code easier to > follow (more explicit/discoverable) for anyone trying to implement support for
Is it really a reasonable usecase to use RAND_bytes() outside of both pg_stroing_random() *and' outside of the openssl-specific files (like be-secure-openssl.c)? Because it would only be those cases that would have this case, right? If anything, perhaps the call to RAND_poll() in fork_process.c should actually be a call to a strong_random_initialize() or something which would have an implementation in pg_strong_random.c, thereby isolating the openssl specific code in there? (And with a void implementation without openssl) -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
