On Tue, Jul 21, 2020 at 10:36:53PM +0200, Daniel Gustafsson wrote:
> I think the original intention was to handle older OpenSSL versions where
> multiple successful RAND_poll calls were required for RAND_status to succeed,
> the check working as an optimization since a failing RAND_poll would render all
> efforts useless anyway. I'm not sure this is true for the OpenSSL versions we
> support in HEAD, and/or for modern platforms, but without proof of it not being
> useful I would opt for keeping it.
Yeah, the retry loop refers to this part of the past discussion on the
matter:
https://www.postgresql.org/message-id/CAEZATCWYs6rAp36VKm4W7Sb3EF_7tNcRuhcnJC1P8=8W9nBm9w@mail.gmail.com
During the rewrite of the RNG engines, there was also a retry logic
introduced in 75e2c87, then removed in c16de9d for 1.1.1. In short,
we may be able to live without that once we cut more support for
OpenSSL versions (minimum version support of 1.1.1 is a couple of
years ahead at least for us), but I see no reasons to not leave that
in place either. And this visibly solved one problem for us. I don't
see either a reason to not simplify the loop to fall back to
RAND_status() for the validation.
In short, the proposed patch set looks like a good idea to me to stick
with the recommendations of upstream's wiki to use RAND_poll() after a
fork, but only do that on HEAD (OpenSSL 1.1.0 mixes the current
timestamp and the PID in the random seed of the default engine, 1.0.2
only the PID but RAND_cleanup is a no-op only after 1.1.0).
--
Michael