Robert Haas <> writes:
> On Mon, Oct 17, 2016 at 1:48 PM, Heikki Linnakangas <> 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

* 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to