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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Date: 2016-10-17 20:35:11
Message-ID: 11757.1476736511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 17, 2016 at 1:48 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2016-10-17 20:53:37 pgsql: By default, set log_line_prefix = '%m [%p] '.
Previous Message Robert Haas 2016-10-17 20:09:55 Re: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-10-17 20:35:51 Re: process type escape for log_line_prefix
Previous Message Andres Freund 2016-10-17 20:19:35 Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1