Re: Move OpenSSL random under USE_OPENSSL_RANDOM

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Move OpenSSL random under USE_OPENSSL_RANDOM
Date: 2020-11-04 01:01:14
Message-ID: 20201104010114.GA1711@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 03, 2020 at 01:46:38PM +0100, Magnus Hagander wrote:
> On Tue, Nov 3, 2020 at 1:00 PM Daniel Gustafsson <daniel(at)yesql(dot)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
}
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-11-04 01:05:44 Fix brin_form_tuple to properly detoast data
Previous Message Greg Nancarrow 2020-11-04 00:41:12 Re: Parallel INSERT (INTO ... SELECT ...)