Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Date
Msg-id 11757.1476736511@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Oct 17, 2016 at 1:48 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> I'm going to try implementing prngd support. It seems easy enough, and prngd
>> can be run on modern systems too, which is important for testing it.

> TBH, if pandemolon is the only system in the BF that doesn't have any
> other source of entropy, I think that's going 100% in the wrong
> direction.  Even with prngd support, this carries a significant risk
> of effectively desupporting a large number of obscure UNIX platforms,
> which I think is a bad decision.  It's fine (IMHO) to have
> optimizations in the code here and there that cater to Windows and
> Linux because those are the most widely-used platfoms, but we've been
> pretty diligent about trying to be portable to a wide variety of
> UNIX-like platforms.  I think that's a good decision, and reversing it
> over the strength of cancel keys seems like letting the tail wag the
> dog.

This is largely my position as well.  A relevant point here is that prngd
did not come with that platform --- I had to install it after the fact.
(If memory serves, which it may not because this was years ago, I did so
because some new version of openssl started whining about lack of an
entropy source.)  Strong cancel keys are simply not important enough to
desupport a bunch of old platforms over.

I'm not convinced either way about pgcrypto.  It's certainly a reasonable
position that you want that to generate sound keys or else fail entirely.
But if nothing else on the platform is generating sound keys, do we want
to insist on being the first?

If we want it to fail, and don't want to retire pademelon, there are
multiple ways we could get to that goal:

* Enable --with-openssl in pademelon's build (don't really want to do
this, since I believe almost all the rest of the buildfarm tests with
openssl)

* Add variant expected-files (probably bad, it'd hide real failures)

* Add a configure option to suppress building/testing pgcrypto (maybe
just make it contingent on --with-openssl, which would allow deletion
of a bunch of code that duplicates openssl functionality...)

* Support reading entropy from prngd (but this means we have no buildfarm
coverage for entropy-daemon-less platforms)

None of these are perfect, but I'd say the last one is not so obviously
the best that we shouldn't consider alternatives.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1
Next
From: Andres Freund
Date:
Subject: Re: process type escape for log_line_prefix