On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 26 Aug 2020, at 09:56, Michael Paquier <michael@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/
