Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |
Дата | |
Msg-id | 28173.1476717663@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a
stronger way of generating ran
Re: [COMMITTERS] pgsql: Replace PostmasterRandom() with a stronger way of generating ran |
Список | pgsql-hackers |
Heikki Linnakangas <hlinnaka@iki.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: if (random_from_file("/dev/random", buf, len)) return true; +#ifdef ALLOW_WEAK_SECURITY + ... old PostmasterRandom method here ... +#endif +/* None of the sources were available. */return false; regards, tom lane
В списке pgsql-hackers по дате отправления: