diff options
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2016-12-05 13:42:59 +0200 |
|---|---|---|
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2016-12-05 13:42:59 +0200 |
| commit | fe0a0b5993dfe24e4b3bcf52fa64ff41a444b8f1 (patch) | |
| tree | 7990f273fde3d545b5ecd2e813930b2077bf15d3 /doc/src | |
| parent | 5dc851afde8d9ef9947f21799f7a1b08bf0bf812 (diff) | |
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/installation.sgml | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 296611d4256..98594a487e6 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1097,6 +1097,23 @@ su - postgres </varlistentry> <varlistentry> + <term><option>--disable-strong-random</option></term> + <listitem> + <para> + Allow the build to succeed even if <productname>PostgreSQL</> + has no support for strong random numbers on the platform. + A source of random numbers is needed for some authentication + protocols, as well as some routines in <xref linkend="pgcrypto"> + module. --disable-strong-random disables functionality that + requires cryptographically strong random numbers, and substitutes + a weak pseudo-random-number-generator for the generation of + authentication salt values and query cancel keys. It may make + authentication less secure. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><option>--disable-thread-safety</option></term> <listitem> <para> |
