Merge from PG master upto d5cb3bab564e0927ffac7c8729eacf181a12dd40

This is the result of the "git merge remotes/PGSQL/master" upto the said commit
point. We have done some basic analysis, fixed compilation problems etc, but
bulk of the logical problems in conflict resolution etc will be handled by
subsequent commits.

1 files changed, 9 insertions, 7 deletions

diff --git a/contrib/pgcrypto/pgp-mpi-internal.c b/contrib/pgcrypto/pgp-mpi-internal.c
index be95f2d092..545009ce19 100644
--- a/contrib/pgcrypto/pgp-mpi-internal.c
+++ b/contrib/pgcrypto/pgp-mpi-internal.c
@@ -57,17 +57,16 @@ mp_clear_free(mpz_t *a)
 static int
 mp_px_rand(uint32 bits, mpz_t *res)
 {
-	int			err;
+#ifdef HAVE_STRONG_RANDOM
 	unsigned	bytes = (bits + 7) / 8;
 	int			last_bits = bits & 7;
 	uint8	   *buf;
 
 	buf = px_alloc(bytes);
-	err = px_get_random_bytes(buf, bytes);
-	if (err < 0)
+	if (!pg_strong_random((char *) buf, bytes))
 	{
 		px_free(buf);
-		return err;
+		return PXE_NO_RANDOM;
 	}
 
 	/* clear unnecessary bits and set last bit to one */
@@ -84,6 +83,9 @@ mp_px_rand(uint32 bits, mpz_t *res)
 	px_free(buf);
 
 	return 0;
+#else
+	return PXE_NO_RANDOM;
+#endif
 }
 
 static void
@@ -139,7 +141,7 @@ bn_to_mpi(mpz_t *bn)
 }
 
 /*
- * Decide the number of bits in the random componont k
+ * Decide the number of bits in the random component k
  *
  * It should be in the same range as p for signing (which
  * is deprecated), but can be much smaller for encrypting.
@@ -147,8 +149,8 @@ bn_to_mpi(mpz_t *bn)
  * Until I research it further, I just mimic gpg behaviour.
  * It has a special mapping table, for values <= 5120,
  * above that it uses 'arbitrary high number'.  Following
- * algorihm hovers 10-70 bits above gpg values.  And for
- * larger p, it uses gpg's algorihm.
+ * algorithm hovers 10-70 bits above gpg values.  And for
+ * larger p, it uses gpg's algorithm.
  *
  * The point is - if k gets large, encryption will be
  * really slow.  It does not matter for decryption.