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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Date: 2016-10-17 15:33:50
Message-ID: CABUevExQO5Z0_2XvDZAN=r7ZoaQ9_sgLp_umR=QwV5SPvxBFUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Mon, Oct 17, 2016 at 8:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> > On 10/17/2016 05:50 PM, Tom Lane wrote:
> >> The real issue here is whether we are willing to say that
> >> Postgres simply does not work anymore on machines without standard
> entropy
> >> sources. Doesn't matter whether the user cares about the strength of
> >> cancel keys, we're just blowing them off. That seems a bit extreme
> >> from here. I think we should be willing to fall back to the old code
> >> if we can't find a real entropy source.
>
> > I'm scared of having pg_strong_random() that is willing to fall back to
> > not-so-strong values. We can rename it, of course, but it seems
> > dangerous to use a weak random-number generator for authentication
> > purposes (query cancel, MD5 salts, SCRAM nonces).
>
> I think that it's probably moot on all modern platforms, and even on
> platforms as old as pademelon, the answer for people who care about
> strong security is "--with-openssl". What I'm on about here is whether
> we should make people who don't care about that jump through hoops.
> Not caring is a perfectly reasonable stance for non-exposed postmasters;
> otherwise we wouldn't have the "trust" auth method.
>
> I would be satisfied with making it a non-default build option, eg
> add this to pg_strong_random:
>

+1 for that approach. I really wouldn't want to see it fall back completely
transparently in case something stops working. But if it's a non-default
build option, that's not a problem, and it should make it possible to make
it work on older platforms.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2016-10-17 17:48:58 Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
Previous Message Tom Lane 2016-10-17 15:21:03 Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-10-17 16:07:20 Re: bit|varbit #, xor operator
Previous Message Stephen Frost 2016-10-17 15:24:52 Re: [PATCH] Better logging of COPY queries if log_statement='all'