- (djm) Added WARNING.RNG file and modified configure to ask users of the

   builtin entropy code to read it.
 - (djm) Prefer builtin regex to PCRE.

3 files changed, 100 insertions, 2 deletions

diff --git a/ChangeLog b/ChangeLog
index a0cc5118..d493affb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+20001025
+ - (djm) Added WARNING.RNG file and modified configure to ask users of the
+   builtin entropy code to read it.
+ - (djm) Prefer builtin regex to PCRE.
+
 20001020
  - (djm) Don't define _REENTRANT for SNI/Reliant Unix
  - (bal) Imported NEWS-OS waitpid() macros into NeXT.  Since implementation
diff --git a/WARNING.RNG b/WARNING.RNG
new file mode 100644
index 00000000..5f129f40
--- /dev/null
+++ b/WARNING.RNG
@@ -0,0 +1,80 @@
+This document contains a description of portable OpenSSH's random
+number collection code. An alternate reading of this text could
+well be titled "Why I should pressure my system vendor to supply
+/dev/random in their OS".
+
+Why is this important? OpenSSH depends on good, unpredictable numbers
+for generating keys, performing digital signatures and forming
+cryptographic challenges. If the random numbers that it uses are
+predictable, then the strength of the whole system is compromised.
+
+A particularly pernicious problem arises with DSA keys (used by the
+ssh2 protocol). Performing a DSA signature (which is required for
+authentication), entails the use of a 160 bit random number.  If an
+attacker can predict this number, then they can deduce your *private*
+key and impersonate you.
+
+If you are using the builtin random number support (configure will
+tell you if this is the case), then read this document in its entirety
+and consider disabling ssh2 support (by adding "Protocol 1" to
+sshd_config and ssh_config).
+
+Please also request that your OS vendor provides a kernel-based random
+number collector (/dev/random) in future versions of your operating
+systems.
+
+On to the description...
+
+The portable OpenSSH contains random number collection support for
+systems which lack a kernel entropy pool (/dev/random).
+
+This collector operates by executing the programs listed in
+($etcdir)/ssh_prng_cmds, reading their output and adding it to the
+PRNG supplied by OpenSSL (which is hash-based). It also stirs in the
+output of several system calls and timings from the execution of the
+programs that it runs.
+
+The ssh_prng_cmds file also specifies a 'rate' for each program. This
+represents the number of bits of randomness per byte of output from
+the specified program.
+
+The random number code will also read and save a seed file to
+~/.ssh/prng_seed. This contents of this file are added to the random
+number generator at startup.
+
+This approach presents two problems:
+
+1. It is slow.
+
+Executing each program in the list can take a large amount of time,   
+especially on slower machines. Additionally some program can take a   
+disproportionate time to execute.                                     
+
+This can be tuned by the administrator. To debug the entropy
+collection is great detail, turn on full debugging ("ssh -v -v -v" or
+"sshd -d -d -d"). This will list each program as it is executed, how
+long it took to execute, its exit status and whether and how much data
+it generated. You can the find the culprit programs which are causing
+the real slow-downs.
+
+The entropy collector will timeout programs which take too long
+to execute, the actual timeout used can be adjusted with the
+--with-entropy-timeout configure option. OpenSSH will not try to
+re-execute programs which have not been found, have had a non-zero
+exit status or have timed out more than a couple of times.
+
+2. Estimating the real 'rate' of program outputs is non-trivial
+
+The shear volume of the task is problematic: there are currently
+around 50 commands in the ssh_prng_cmds list, portable OpenSSH
+supports at least 12 different OSs. That is already 600 sets of data
+to be analysed, without taking into account the numerous differences
+between versions of each OS.
+
+On top of this, the different commands can produce varying amounts of
+usable data depending on how busy the machine is, how long it has been
+up and various other factors.
+
+To make matters even more complex, some of the commands are reporting
+largely the same data as other commands (eg. the various "ps" calls).
+
diff --git a/configure.in b/configure.in
index ed4d0519..90e75bef 100644
--- a/configure.in
+++ b/configure.in
@@ -266,8 +266,14 @@ AC_ARG_WITH(libs,
 # Checks for libraries.
 AC_CHECK_LIB(z, deflate, ,AC_MSG_ERROR([*** zlib missing - please install first ***]))
 AC_CHECK_LIB(util, login, AC_DEFINE(HAVE_LIBUTIL_LOGIN) LIBS="$LIBS -lutil")
-AC_CHECK_LIB(pcre, pcre_info, 
-	AC_DEFINE(HAVE_LIBPCRE) LIBS="$LIBS -lpcreposix -lpcre")
+
+AC_CHECK_FUNC(regcomp, 
+	[],
+	[
+		AC_CHECK_LIB(pcre, pcre_info, 
+			AC_DEFINE(HAVE_LIBPCRE) LIBS="$LIBS -lpcreposix -lpcre")
+	]
+)
 
 if test -z "$no_libsocket" ; then
 	AC_CHECK_LIB(nsl, yp_match, , )
@@ -1531,6 +1537,7 @@ else
 		RAND_MSG="EGD ($EGD_SOCKET)"
 	else
 		RAND_MSG="Builtin (timeout $entropy_timeout)"
+		BUILTIN_RNG=1
 	fi
 fi
 
@@ -1574,3 +1581,9 @@ echo "        Libraries: ${LIBS}"
 
 echo ""
 
+if test ! -z "$BUILTIN_RNG" ; then
+	echo "WARNING: you are using the builtin random number collection service."
+	echo "Please read WARNING.RNG and request that your OS vendor includes"
+	echo "/dev/random in future versions of their OS."
+	echo ""
+fi