Re: Removing --disable-strong-random from the code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Removing --disable-strong-random from the code
Date: 2018-12-30 16:47:03
Message-ID: 20186.1546188423@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> And attached is an updated patch with all those fixes included. Any
> thoughts or opinions?

contrib/pgcrypto has some variant expected-files for the no-strong-random
case that could be removed now.

BackendRandomLock should be removed, too.

Since pg_strong_random is declared to take "void *", the places that
cast arguments to "char *" could be simplified. (I guess that's a
hangover from the rather random decision to make pg_backend_random
take char *?)

The wording for pgcrypto's PXE_NO_RANDOM error,

{PXE_NO_RANDOM, "No strong random source"},

perhaps needs to be changed --- maybe "Failed to generate strong random bits"?

Not the fault of this patch, but surely this bit in pgcrypto's
pad_eme_pkcs1_v15()

if (!pg_strong_random((char *) p, 1))
{
px_memset(buf, 0, res_len);
px_free(buf);
break;
}

is insane, because the "break" makes it fall into code that will continue
to scribble on "buf". I think the "break" needs to be "return
PXE_NO_RANDOM", and probably we'd better back-patch that as a bug fix.
(I'm also failing to see the point of that px_memset before freeing the
buffer --- at this point, it contains no sensitive data, surely.)

LGTM otherwise.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-30 16:56:48 Re: Removing --disable-strong-random from the code
Previous Message Noah Misch 2018-12-30 16:28:56 Re: Move regression.diffs of pg_upgrade test suite