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
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 |