On Wed, Nov 4, 2020 at 2:01 AM Michael Paquier <mich...@paquier.xyz> wrote:
>
> On Tue, Nov 03, 2020 at 01:46:38PM +0100, Magnus Hagander wrote:
> > On Tue, Nov 3, 2020 at 1:00 PM Daniel Gustafsson <dan...@yesql.se> wrote:
> >> I kind of like the idea of continuing to abstract this functionality, not
> >> pulling in OpenSSL headers in fork_process.c is a neat bonus. I'd say it's
> >> worth implementing to see what it would imply, and am happy to do unless
> >> someone beats me to it.
> >
> > Yeah, if it's likely to be usable in the other implementations, then I
> > think we should definitely explore exactly what that kind of an
> > abstraction would imply. Anything isolating the dependency on OpenSSL
> > would likely have to be done at that time anyway in that case, so
> > better have it ready.
>
> With the NSS argument, agreed. Documenting when this initialization
> routine is used is important. And I think that we should force to
> look at this code when adding a new SSL implementation to make sure
> that we never see CVE-2013-1900 again, say:
> void
> pg_strong_random_init(void)
> {
> #ifdef USE_SSL
> #ifdef USE_OPENSSL
> RAND_poll();
> #elif USE_NSS
> /* do the NSS initialization */
> #else
> Hey, you are missing something here.
> #endif
> #endif
> }
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.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
