path: root/abs/core/openssl/fix-manpages.patch

--- crypto/rand/md_rand.c	2009-01-03 10:25:32.000000000 +0100
+++ crypto/rand/md_rand.c	2010-04-01 00:45:00.746327192 +0200
@@ -196,7 +196,7 @@
 	int do_not_lock;
 
 	/*
-	 * (Based on the rand(3) manpage)
+	 * (Based on the openssl_rand(3) manpage)
 	 *
 	 * The input is chopped up into units of 20 bytes (or less for
 	 * the last block).  Each of these blocks is run through the hash
@@ -361,7 +361,7 @@
 	num_ceil = (1 + (num-1)/(MD_DIGEST_LENGTH/2)) * (MD_DIGEST_LENGTH/2);
 
 	/*
-	 * (Based on the rand(3) manpage:)
+	 * (Based on the openssl_rand(3) manpage)
 	 *
 	 * For each group of 10 bytes (or less), we do the following:
 	 *
--- doc/apps/openssl-passwd.pod	1970-01-01 01:00:00.000000000 +0100
+++ doc/apps/openssl-passwd.pod	2010-04-01 00:45:00.796327220 +0200
@@ -0,0 +1,82 @@
+=pod
+
+=head1 NAME
+
+openssl-passwd - compute password hashes
+
+=head1 SYNOPSIS
+
+B<openssl passwd>
+[B<-crypt>]
+[B<-1>]
+[B<-apr1>]
+[B<-salt> I<string>]
+[B<-in> I<file>]
+[B<-stdin>]
+[B<-noverify>]
+[B<-quiet>]
+[B<-table>]
+{I<password>}
+
+=head1 DESCRIPTION
+
+The B<passwd> command computes the hash of a password typed at
+run-time or the hash of each password in a list.  The password list is
+taken from the named file for option B<-in file>, from stdin for
+option B<-stdin>, or from the command line, or from the terminal otherwise.
+The Unix standard algorithm B<crypt> and the MD5-based BSD password
+algorithm B<1> and its Apache variant B<apr1> are available.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-crypt>
+
+Use the B<crypt> algorithm (default).
+
+=item B<-1>
+
+Use the MD5 based BSD password algorithm B<1>.
+
+=item B<-apr1>
+
+Use the B<apr1> algorithm (Apache variant of the BSD algorithm).
+
+=item B<-salt> I<string>
+
+Use the specified salt.
+When reading a password from the terminal, this implies B<-noverify>.
+
+=item B<-in> I<file>
+
+Read passwords from I<file>.
+
+=item B<-stdin>
+
+Read passwords from B<stdin>.
+
+=item B<-noverify>
+
+Don't verify when reading a password from the terminal.
+
+=item B<-quiet>
+
+Don't output warnings when passwords given at the command line are truncated.
+
+=item B<-table>
+
+In the output list, prepend the cleartext password and a TAB character
+to each password hash.
+
+=back
+
+=head1 EXAMPLES
+
+B<openssl passwd -crypt -salt xx password> prints B<xxj31ZMTZzkVA>.
+
+B<openssl passwd -1 -salt xxxxxxxx password> prints B<$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.>.
+
+B<openssl passwd -apr1 -salt xxxxxxxx password> prints B<$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0>.
+
+=cut
--- doc/apps/openssl.pod	2010-01-21 19:46:28.000000000 +0100
+++ doc/apps/openssl.pod	2010-04-01 00:45:00.796327220 +0200
@@ -163,7 +163,7 @@
 
 Online Certificate Status Protocol utility.
 
-=item L<B<passwd>|passwd(1)>
+=item L<B<passwd>|openssl-passwd(1)>
 
 Generation of hashed passwords.
 
@@ -401,7 +401,7 @@
 L<dhparam(1)|dhparam(1)>, L<dsa(1)|dsa(1)>, L<dsaparam(1)|dsaparam(1)>,
 L<enc(1)|enc(1)>, L<gendsa(1)|gendsa(1)>, L<genpkey(1)|genpkey(1)>,
 L<genrsa(1)|genrsa(1)>, L<nseq(1)|nseq(1)>, L<openssl(1)|openssl(1)>,
-L<passwd(1)|passwd(1)>,
+L<openssl-passwd(1)|openssl-passwd(1)>,
 L<pkcs12(1)|pkcs12(1)>, L<pkcs7(1)|pkcs7(1)>, L<pkcs8(1)|pkcs8(1)>,
 L<rand(1)|rand(1)>, L<req(1)|req(1)>, L<rsa(1)|rsa(1)>,
 L<rsautl(1)|rsautl(1)>, L<s_client(1)|s_client(1)>,
--- doc/apps/passwd.pod	2002-10-04 14:59:00.000000000 +0200
+++ doc/apps/passwd.pod	1970-01-01 01:00:00.000000000 +0100
@@ -1,82 +0,0 @@
-=pod
-
-=head1 NAME
-
-passwd - compute password hashes
-
-=head1 SYNOPSIS
-
-B<openssl passwd>
-[B<-crypt>]
-[B<-1>]
-[B<-apr1>]
-[B<-salt> I<string>]
-[B<-in> I<file>]
-[B<-stdin>]
-[B<-noverify>]
-[B<-quiet>]
-[B<-table>]
-{I<password>}
-
-=head1 DESCRIPTION
-
-The B<passwd> command computes the hash of a password typed at
-run-time or the hash of each password in a list.  The password list is
-taken from the named file for option B<-in file>, from stdin for
-option B<-stdin>, or from the command line, or from the terminal otherwise.
-The Unix standard algorithm B<crypt> and the MD5-based BSD password
-algorithm B<1> and its Apache variant B<apr1> are available.
-
-=head1 OPTIONS
-
-=over 4
-
-=item B<-crypt>
-
-Use the B<crypt> algorithm (default).
-
-=item B<-1>
-
-Use the MD5 based BSD password algorithm B<1>.
-
-=item B<-apr1>
-
-Use the B<apr1> algorithm (Apache variant of the BSD algorithm).
-
-=item B<-salt> I<string>
-
-Use the specified salt.
-When reading a password from the terminal, this implies B<-noverify>.
-
-=item B<-in> I<file>
-
-Read passwords from I<file>.
-
-=item B<-stdin>
-
-Read passwords from B<stdin>.
-
-=item B<-noverify>
-
-Don't verify when reading a password from the terminal.
-
-=item B<-quiet>
-
-Don't output warnings when passwords given at the command line are truncated.
-
-=item B<-table>
-
-In the output list, prepend the cleartext password and a TAB character
-to each password hash.
-
-=back
-
-=head1 EXAMPLES
-
-B<openssl passwd -crypt -salt xx password> prints B<xxj31ZMTZzkVA>.
-
-B<openssl passwd -1 -salt xxxxxxxx password> prints B<$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.>.
-
-B<openssl passwd -apr1 -salt xxxxxxxx password> prints B<$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0>.
-
-=cut
--- doc/crypto/BN_generate_prime.pod	2003-01-13 14:18:22.000000000 +0100
+++ doc/crypto/BN_generate_prime.pod	2010-04-01 00:45:00.824035190 +0200
@@ -90,7 +90,7 @@
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>
 
 =head1 HISTORY
 
--- doc/crypto/bn.pod	2008-07-03 21:59:24.000000000 +0200
+++ doc/crypto/bn.pod	2010-04-01 00:45:01.022993777 +0200
@@ -167,7 +167,7 @@
 =head1 SEE ALSO
 
 L<bn_internal(3)|bn_internal(3)>,
-L<dh(3)|dh(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
+L<dh(3)|dh(3)>, L<openssl_err(3)|openssl_err(3)>, L<openssl_rand(3)|openssl_rand(3)>, L<rsa(3)|rsa(3)>,
 L<BN_new(3)|BN_new(3)>, L<BN_CTX_new(3)|BN_CTX_new(3)>,
 L<BN_copy(3)|BN_copy(3)>, L<BN_swap(3)|BN_swap(3)>, L<BN_num_bytes(3)|BN_num_bytes(3)>,
 L<BN_add(3)|BN_add(3)>, L<BN_add_word(3)|BN_add_word(3)>,
--- doc/crypto/BN_rand.pod	2002-09-25 15:33:26.000000000 +0200
+++ doc/crypto/BN_rand.pod	2010-04-01 00:45:00.824035190 +0200
@@ -45,7 +45,7 @@
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<RAND_add(3)|RAND_add(3)>, L<RAND_bytes(3)|RAND_bytes(3)>
 
 =head1 HISTORY
--- doc/crypto/CONF_modules_free.pod	2006-12-21 22:13:27.000000000 +0100
+++ doc/crypto/CONF_modules_free.pod	2010-04-01 00:45:00.827162198 +0200
@@ -37,7 +37,7 @@
 =head1 SEE ALSO
 
 L<conf(5)|conf(5)>, L<OPENSSL_config(3)|OPENSSL_config(3)>,
-L<CONF_modules_load_file(3), CONF_modules_load_file(3)>
+L<CONF_modules_load_file(3)|CONF_modules_load_file(3)>
 
 =head1 HISTORY
 
--- doc/crypto/CONF_modules_load_file.pod	2004-03-02 14:31:32.000000000 +0100
+++ doc/crypto/CONF_modules_load_file.pod	2010-04-01 00:45:00.833827289 +0200
@@ -51,7 +51,7 @@
 =head1 SEE ALSO
 
 L<conf(5)|conf(5)>, L<OPENSSL_config(3)|OPENSSL_config(3)>,
-L<CONF_free(3), CONF_free(3)>, L<err(3),err(3)>
+L<CONF_free(3)|CONF_free(3)>, L<openssl_err(3)|openssl_err(3)>
 
 =head1 HISTORY
 
--- doc/crypto/crypto.pod	2002-10-06 14:59:25.000000000 +0200
+++ doc/crypto/crypto.pod	2010-04-01 00:45:01.029660428 +0200
@@ -46,7 +46,7 @@
 
 =item AUXILIARY FUNCTIONS
 
-L<err(3)|err(3)>, L<threads(3)|threads(3)>, L<rand(3)|rand(3)>,
+L<openssl_err(3)|openssl_err(3)>, L<openssl_threads(3)|openssl_threads(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<OPENSSL_VERSION_NUMBER(3)|OPENSSL_VERSION_NUMBER(3)>
 
 =item INPUT/OUTPUT, DATA ENCODING
--- doc/crypto/des.pod	2003-10-01 17:02:45.000000000 +0200
+++ doc/crypto/des.pod	2010-04-01 00:45:01.036327160 +0200
@@ -115,7 +115,7 @@
 the key; it is used to speed the encryption process.
 
 DES_random_key() generates a random key.  The PRNG must be seeded
-prior to using this function (see L<rand(3)|rand(3)>).  If the PRNG
+prior to using this function (see L<openssl_rand(3)|openssl_rand(3)>).  If the PRNG
 could not generate a secure key, 0 is returned.
 
 Before a DES key can be used, it must be converted into the
@@ -317,7 +317,7 @@
 
 =head1 SEE ALSO
 
-crypt(3), L<des_modes(7)|des_modes(7)>, L<evp(3)|evp(3)>, L<rand(3)|rand(3)>
+crypt(3), L<des_modes(7)|des_modes(7)>, L<evp(3)|evp(3)>, L<openssl_rand(3)|openssl_rand(3)>
 
 =head1 HISTORY
 
--- doc/crypto/DH_generate_key.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DH_generate_key.pod	2010-04-01 00:45:00.840494142 +0200
@@ -40,7 +40,7 @@
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<DH_size(3)|DH_size(3)>
+L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>, L<DH_size(3)|DH_size(3)>
 
 =head1 HISTORY
 
--- doc/crypto/DH_generate_parameters.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DH_generate_parameters.pod	2010-04-01 00:45:00.847161913 +0200
@@ -59,7 +59,7 @@
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<DH_free(3)|DH_free(3)>
 
 =head1 HISTORY
--- doc/crypto/dh.pod	2002-08-05 18:27:01.000000000 +0200
+++ doc/crypto/dh.pod	2010-04-01 00:45:01.036327160 +0200
@@ -67,8 +67,8 @@
 
 =head1 SEE ALSO
 
-L<dhparam(1)|dhparam(1)>, L<bn(3)|bn(3)>, L<dsa(3)|dsa(3)>, L<err(3)|err(3)>,
-L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<engine(3)|engine(3)>,
+L<dhparam(1)|dhparam(1)>, L<bn(3)|bn(3)>, L<dsa(3)|dsa(3)>, L<openssl_err(3)|openssl_err(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<rsa(3)|rsa(3)>, L<engine(3)|engine(3)>,
 L<DH_set_method(3)|DH_set_method(3)>, L<DH_new(3)|DH_new(3)>,
 L<DH_get_ex_new_index(3)|DH_get_ex_new_index(3)>,
 L<DH_generate_parameters(3)|DH_generate_parameters(3)>,
--- doc/crypto/DSA_do_sign.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DSA_do_sign.pod	2010-04-01 00:45:00.847161913 +0200
@@ -36,7 +36,7 @@
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<DSA_SIG_new(3)|DSA_SIG_new(3)>,
 L<DSA_sign(3)|DSA_sign(3)>
 
--- doc/crypto/DSA_generate_key.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DSA_generate_key.pod	2010-04-01 00:45:00.847161913 +0200
@@ -24,7 +24,7 @@
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<DSA_generate_parameters(3)|DSA_generate_parameters(3)>
 
 =head1 HISTORY
--- doc/crypto/DSA_generate_parameters.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DSA_generate_parameters.pod	2010-04-01 00:45:00.847161913 +0200
@@ -90,7 +90,7 @@
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<DSA_free(3)|DSA_free(3)>
 
 =head1 HISTORY
--- doc/crypto/dsa.pod	2002-08-05 18:27:01.000000000 +0200
+++ doc/crypto/dsa.pod	2010-04-01 00:45:01.042994012 +0200
@@ -100,7 +100,7 @@
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<dh(3)|dh(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>,
+L<bn(3)|bn(3)>, L<dh(3)|dh(3)>, L<openssl_err(3)|openssl_err(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<rsa(3)|rsa(3)>, L<sha(3)|sha(3)>, L<engine(3)|engine(3)>,
 L<DSA_new(3)|DSA_new(3)>,
 L<DSA_size(3)|DSA_size(3)>,
--- doc/crypto/DSA_sign.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/DSA_sign.pod	2010-04-01 00:45:00.847161913 +0200
@@ -55,7 +55,7 @@
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<DSA_do_sign(3)|DSA_do_sign(3)>
 
 =head1 HISTORY
--- doc/crypto/engine.pod	2007-11-19 10:18:03.000000000 +0100
+++ doc/crypto/engine.pod	2010-04-01 00:45:01.049660583 +0200
@@ -594,6 +594,6 @@
 
 =head1 SEE ALSO
 
-L<rsa(3)|rsa(3)>, L<dsa(3)|dsa(3)>, L<dh(3)|dh(3)>, L<rand(3)|rand(3)>
+L<rsa(3)|rsa(3)>, L<dsa(3)|dsa(3)>, L<dh(3)|dh(3)>, L<openssl_rand(3)|openssl_rand(3)>
 
 =cut
--- doc/crypto/ERR_clear_error.pod	2000-02-01 02:36:58.000000000 +0100
+++ doc/crypto/ERR_clear_error.pod	2010-04-01 00:45:00.857161750 +0200
@@ -20,7 +20,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
+L<openssl_err(3)|openssl_err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
--- doc/crypto/ERR_error_string.pod	2004-11-14 16:11:37.000000000 +0100
+++ doc/crypto/ERR_error_string.pod	2010-04-01 00:45:00.863828202 +0200
@@ -60,7 +60,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
+L<openssl_err(3)|openssl_err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
 L<ERR_load_crypto_strings(3)|ERR_load_crypto_strings(3)>,
 L<SSL_load_error_strings(3)|SSL_load_error_strings(3)>
 L<ERR_print_errors(3)|ERR_print_errors(3)>
--- doc/crypto/ERR_get_error.pod	2002-11-29 15:21:54.000000000 +0100
+++ doc/crypto/ERR_get_error.pod	2010-04-01 00:45:00.870494614 +0200
@@ -61,7 +61,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>,
+L<openssl_err(3)|openssl_err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>,
 L<ERR_GET_LIB(3)|ERR_GET_LIB(3)>
 
 =head1 HISTORY
--- doc/crypto/ERR_GET_LIB.pod	2000-02-01 02:36:58.000000000 +0100
+++ doc/crypto/ERR_GET_LIB.pod	2010-04-01 00:45:00.850495218 +0200
@@ -41,7 +41,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
+L<openssl_err(3)|openssl_err(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
--- doc/crypto/ERR_load_crypto_strings.pod	2000-02-24 12:55:08.000000000 +0100
+++ doc/crypto/ERR_load_crypto_strings.pod	2010-04-01 00:45:00.873827919 +0200
@@ -35,7 +35,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>
+L<openssl_err(3)|openssl_err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>
 
 =head1 HISTORY
 
--- doc/crypto/ERR_load_strings.pod	2000-02-24 12:55:08.000000000 +0100
+++ doc/crypto/ERR_load_strings.pod	2010-04-01 00:45:00.876327759 +0200
@@ -43,7 +43,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_load_strings(3)|ERR_load_strings(3)>
+L<openssl_err(3)|openssl_err(3)>, L<ERR_load_strings(3)|ERR_load_strings(3)>
 
 =head1 HISTORY
 
--- doc/crypto/err.pod	2002-07-10 21:35:46.000000000 +0200
+++ doc/crypto/err.pod	1970-01-01 01:00:00.000000000 +0100
@@ -1,187 +0,0 @@
-=pod
-
-=head1 NAME
-
-err - error codes
-
-=head1 SYNOPSIS
-
- #include <openssl/err.h>
-
- unsigned long ERR_get_error(void);
- unsigned long ERR_peek_error(void);
- unsigned long ERR_get_error_line(const char **file, int *line);
- unsigned long ERR_peek_error_line(const char **file, int *line);
- unsigned long ERR_get_error_line_data(const char **file, int *line,
-         const char **data, int *flags);
- unsigned long ERR_peek_error_line_data(const char **file, int *line,
-         const char **data, int *flags);
-
- int ERR_GET_LIB(unsigned long e);
- int ERR_GET_FUNC(unsigned long e);
- int ERR_GET_REASON(unsigned long e);
-
- void ERR_clear_error(void);
-
- char *ERR_error_string(unsigned long e, char *buf);
- const char *ERR_lib_error_string(unsigned long e);
- const char *ERR_func_error_string(unsigned long e);
- const char *ERR_reason_error_string(unsigned long e);
-
- void ERR_print_errors(BIO *bp);
- void ERR_print_errors_fp(FILE *fp);
-
- void ERR_load_crypto_strings(void);
- void ERR_free_strings(void);
-
- void ERR_remove_state(unsigned long pid);
-
- void ERR_put_error(int lib, int func, int reason, const char *file,
-         int line);
- void ERR_add_error_data(int num, ...);
-
- void ERR_load_strings(int lib,ERR_STRING_DATA str[]);
- unsigned long ERR_PACK(int lib, int func, int reason);
- int ERR_get_next_error_library(void);
-
-=head1 DESCRIPTION
-
-When a call to the OpenSSL library fails, this is usually signalled
-by the return value, and an error code is stored in an error queue
-associated with the current thread. The B<err> library provides
-functions to obtain these error codes and textual error messages.
-
-The L<ERR_get_error(3)|ERR_get_error(3)> manpage describes how to
-access error codes.
-
-Error codes contain information about where the error occurred, and
-what went wrong. L<ERR_GET_LIB(3)|ERR_GET_LIB(3)> describes how to
-extract this information. A method to obtain human-readable error
-messages is described in L<ERR_error_string(3)|ERR_error_string(3)>.
-
-L<ERR_clear_error(3)|ERR_clear_error(3)> can be used to clear the
-error queue.
-
-Note that L<ERR_remove_state(3)|ERR_remove_state(3)> should be used to
-avoid memory leaks when threads are terminated.
-
-=head1 ADDING NEW ERROR CODES TO OPENSSL
-
-See L<ERR_put_error(3)> if you want to record error codes in the
-OpenSSL error system from within your application.
-
-The remainder of this section is of interest only if you want to add
-new error codes to OpenSSL or add error codes from external libraries.
-
-=head2 Reporting errors
-
-Each sub-library has a specific macro XXXerr() that is used to report
-errors. Its first argument is a function code B<XXX_F_...>, the second
-argument is a reason code B<XXX_R_...>. Function codes are derived
-from the function names; reason codes consist of textual error
-descriptions. For example, the function ssl23_read() reports a
-"handshake failure" as follows:
-
- SSLerr(SSL_F_SSL23_READ, SSL_R_SSL_HANDSHAKE_FAILURE);
-
-Function and reason codes should consist of upper case characters,
-numbers and underscores only. The error file generation script translates
-function codes into function names by looking in the header files
-for an appropriate function name, if none is found it just uses
-the capitalized form such as "SSL23_READ" in the above example.
-
-The trailing section of a reason code (after the "_R_") is translated
-into lower case and underscores changed to spaces.
-
-When you are using new function or reason codes, run B<make errors>.
-The necessary B<#define>s will then automatically be added to the
-sub-library's header file.
-
-Although a library will normally report errors using its own specific
-XXXerr macro, another library's macro can be used. This is normally
-only done when a library wants to include ASN1 code which must use
-the ASN1err() macro.
-
-=head2 Adding new libraries
-
-When adding a new sub-library to OpenSSL, assign it a library number
-B<ERR_LIB_XXX>, define a macro XXXerr() (both in B<err.h>), add its
-name to B<ERR_str_libraries[]> (in B<crypto/err/err.c>), and add
-C<ERR_load_XXX_strings()> to the ERR_load_crypto_strings() function
-(in B<crypto/err/err_all.c>). Finally, add an entry
-
- L	XXX	xxx.h	xxx_err.c
-
-to B<crypto/err/openssl.ec>, and add B<xxx_err.c> to the Makefile.
-Running B<make errors> will then generate a file B<xxx_err.c>, and
-add all error codes used in the library to B<xxx.h>.
-
-Additionally the library include file must have a certain form.
-Typically it will initially look like this:
-
- #ifndef HEADER_XXX_H
- #define HEADER_XXX_H
-
- #ifdef __cplusplus
- extern "C" {
- #endif
-
- /* Include files */
-
- #include <openssl/bio.h>
- #include <openssl/x509.h>
-
- /* Macros, structures and function prototypes */
-
-
- /* BEGIN ERROR CODES */
-
-The B<BEGIN ERROR CODES> sequence is used by the error code
-generation script as the point to place new error codes, any text
-after this point will be overwritten when B<make errors> is run.
-The closing #endif etc will be automatically added by the script.
-
-The generated C error code file B<xxx_err.c> will load the header
-files B<stdio.h>, B<openssl/err.h> and B<openssl/xxx.h> so the
-header file must load any additional header files containing any
-definitions it uses.
-
-=head1 USING ERROR CODES IN EXTERNAL LIBRARIES
-
-It is also possible to use OpenSSL's error code scheme in external
-libraries. The library needs to load its own codes and call the OpenSSL
-error code insertion script B<mkerr.pl> explicitly to add codes to
-the header file and generate the C error code file. This will normally
-be done if the external library needs to generate new ASN1 structures
-but it can also be used to add more general purpose error code handling.
-
-TBA more details
-
-=head1 INTERNALS
-
-The error queues are stored in a hash table with one B<ERR_STATE>
-entry for each pid. ERR_get_state() returns the current thread's
-B<ERR_STATE>. An B<ERR_STATE> can hold up to B<ERR_NUM_ERRORS> error
-codes. When more error codes are added, the old ones are overwritten,
-on the assumption that the most recent errors are most important.
-
-Error strings are also stored in hash table. The hash tables can
-be obtained by calling ERR_get_err_state_table(void) and
-ERR_get_string_table(void) respectively.
-
-=head1 SEE ALSO
-
-L<CRYPTO_set_id_callback(3)|CRYPTO_set_id_callback(3)>,
-L<CRYPTO_set_locking_callback(3)|CRYPTO_set_locking_callback(3)>,
-L<ERR_get_error(3)|ERR_get_error(3)>,
-L<ERR_GET_LIB(3)|ERR_GET_LIB(3)>,
-L<ERR_clear_error(3)|ERR_clear_error(3)>,
-L<ERR_error_string(3)|ERR_error_string(3)>,
-L<ERR_print_errors(3)|ERR_print_errors(3)>,
-L<ERR_load_crypto_strings(3)|ERR_load_crypto_strings(3)>,
-L<ERR_remove_state(3)|ERR_remove_state(3)>,
-L<ERR_put_error(3)|ERR_put_error(3)>,
-L<ERR_load_strings(3)|ERR_load_strings(3)>,
-L<SSL_get_error(3)|SSL_get_error(3)>
-
-=cut
--- doc/crypto/ERR_print_errors.pod	2000-02-01 02:36:59.000000000 +0100
+++ doc/crypto/ERR_print_errors.pod	2010-04-01 00:45:00.879660945 +0200
@@ -38,7 +38,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>,
+L<openssl_err(3)|openssl_err(3)>, L<ERR_error_string(3)|ERR_error_string(3)>,
 L<ERR_get_error(3)|ERR_get_error(3)>,
 L<ERR_load_crypto_strings(3)|ERR_load_crypto_strings(3)>,
 L<SSL_load_error_strings(3)|SSL_load_error_strings(3)>
--- doc/crypto/ERR_put_error.pod	2000-02-24 12:55:08.000000000 +0100
+++ doc/crypto/ERR_put_error.pod	2010-04-01 00:45:00.886327158 +0200
@@ -34,7 +34,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<ERR_load_strings(3)|ERR_load_strings(3)>
+L<openssl_err(3)|openssl_err(3)>, L<ERR_load_strings(3)|ERR_load_strings(3)>
 
 =head1 HISTORY
 
--- doc/crypto/ERR_remove_state.pod	2000-05-19 09:54:42.000000000 +0200
+++ doc/crypto/ERR_remove_state.pod	2010-04-01 00:45:00.892994288 +0200
@@ -25,7 +25,7 @@
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>
+L<openssl_err(3)|openssl_err(3)>
 
 =head1 HISTORY
 
--- doc/crypto/EVP_BytesToKey.pod	2004-11-25 18:47:30.000000000 +0100
+++ doc/crypto/EVP_BytesToKey.pod	2010-04-01 00:45:00.899660540 +0200
@@ -59,7 +59,7 @@
 
 =head1 SEE ALSO
 
-L<evp(3)|evp(3)>, L<rand(3)|rand(3)>,
+L<evp(3)|evp(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>
 
 =head1 HISTORY
--- doc/crypto/EVP_OpenInit.pod	2000-09-23 09:16:14.000000000 +0200
+++ doc/crypto/EVP_OpenInit.pod	2010-04-01 00:45:00.906327633 +0200
@@ -54,7 +54,7 @@
 
 =head1 SEE ALSO
 
-L<evp(3)|evp(3)>, L<rand(3)|rand(3)>,
+L<evp(3)|evp(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>,
 L<EVP_SealInit(3)|EVP_SealInit(3)>
 
--- doc/crypto/EVP_SealInit.pod	2005-03-29 19:50:08.000000000 +0200
+++ doc/crypto/EVP_SealInit.pod	2010-04-01 00:45:00.912995642 +0200
@@ -74,7 +74,7 @@
 
 =head1 SEE ALSO
 
-L<evp(3)|evp(3)>, L<rand(3)|rand(3)>,
+L<evp(3)|evp(3)>, L<openssl_rand(3)|openssl_rand(3)>,
 L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>,
 L<EVP_OpenInit(3)|EVP_OpenInit(3)>
 
--- doc/crypto/EVP_SignInit.pod	2006-07-12 14:31:29.000000000 +0200
+++ doc/crypto/EVP_SignInit.pod	2010-04-01 00:45:00.919661935 +0200
@@ -89,7 +89,7 @@
 =head1 SEE ALSO
 
 L<EVP_VerifyInit(3)|EVP_VerifyInit(3)>,
-L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<err(3)|err(3)>,
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<openssl_err(3)|openssl_err(3)>,
 L<evp(3)|evp(3)>, L<hmac(3)|hmac(3)>, L<md2(3)|md2(3)>,
 L<md5(3)|md5(3)>, L<mdc2(3)|mdc2(3)>, L<ripemd(3)|ripemd(3)>,
 L<sha(3)|sha(3)>, L<dgst(1)|dgst(1)>
--- doc/crypto/EVP_VerifyInit.pod	2006-07-12 14:31:30.000000000 +0200
+++ doc/crypto/EVP_VerifyInit.pod	2010-04-01 00:45:00.926327388 +0200
@@ -80,7 +80,7 @@
 
 L<evp(3)|evp(3)>,
 L<EVP_SignInit(3)|EVP_SignInit(3)>,
-L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<err(3)|err(3)>,
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<openssl_err(3)|openssl_err(3)>,
 L<evp(3)|evp(3)>, L<hmac(3)|hmac(3)>, L<md2(3)|md2(3)>,
 L<md5(3)|md5(3)>, L<mdc2(3)|mdc2(3)>, L<ripemd(3)|ripemd(3)>,
 L<sha(3)|sha(3)>, L<dgst(1)|dgst(1)>
--- doc/crypto/OPENSSL_config.pod	2005-06-03 01:19:56.000000000 +0200
+++ doc/crypto/OPENSSL_config.pod	2010-04-01 00:45:00.932995118 +0200
@@ -73,7 +73,7 @@
 =head1 SEE ALSO
 
 L<conf(5)|conf(5)>, L<CONF_load_modules_file(3)|CONF_load_modules_file(3)>,
-L<CONF_modules_free(3),CONF_modules_free(3)>
+L<CONF_modules_free(3)|CONF_modules_free(3)>
 
 =head1 HISTORY
 
--- doc/crypto/openssl_err.pod	1970-01-01 01:00:00.000000000 +0100
+++ doc/crypto/openssl_err.pod	2010-04-01 00:45:01.059660101 +0200
@@ -0,0 +1,187 @@
+=pod
+
+=head1 NAME
+
+openssl_err - error codes
+
+=head1 SYNOPSIS
+
+ #include <openssl/err.h>
+
+ unsigned long ERR_get_error(void);
+ unsigned long ERR_peek_error(void);
+ unsigned long ERR_get_error_line(const char **file, int *line);
+ unsigned long ERR_peek_error_line(const char **file, int *line);
+ unsigned long ERR_get_error_line_data(const char **file, int *line,
+         const char **data, int *flags);
+ unsigned long ERR_peek_error_line_data(const char **file, int *line,
+         const char **data, int *flags);
+
+ int ERR_GET_LIB(unsigned long e);
+ int ERR_GET_FUNC(unsigned long e);
+ int ERR_GET_REASON(unsigned long e);
+
+ void ERR_clear_error(void);
+
+ char *ERR_error_string(unsigned long e, char *buf);
+ const char *ERR_lib_error_string(unsigned long e);
+ const char *ERR_func_error_string(unsigned long e);
+ const char *ERR_reason_error_string(unsigned long e);
+
+ void ERR_print_errors(BIO *bp);
+ void ERR_print_errors_fp(FILE *fp);
+
+ void ERR_load_crypto_strings(void);
+ void ERR_free_strings(void);
+
+ void ERR_remove_state(unsigned long pid);
+
+ void ERR_put_error(int lib, int func, int reason, const char *file,
+         int line);
+ void ERR_add_error_data(int num, ...);
+
+ void ERR_load_strings(int lib,ERR_STRING_DATA str[]);
+ unsigned long ERR_PACK(int lib, int func, int reason);
+ int ERR_get_next_error_library(void);
+
+=head1 DESCRIPTION
+
+When a call to the OpenSSL library fails, this is usually signalled
+by the return value, and an error code is stored in an error queue
+associated with the current thread. The B<err> library provides
+functions to obtain these error codes and textual error messages.
+
+The L<ERR_get_error(3)|ERR_get_error(3)> manpage describes how to
+access error codes.
+
+Error codes contain information about where the error occurred, and
+what went wrong. L<ERR_GET_LIB(3)|ERR_GET_LIB(3)> describes how to
+extract this information. A method to obtain human-readable error
+messages is described in L<ERR_error_string(3)|ERR_error_string(3)>.
+
+L<ERR_clear_error(3)|ERR_clear_error(3)> can be used to clear the
+error queue.
+
+Note that L<ERR_remove_state(3)|ERR_remove_state(3)> should be used to
+avoid memory leaks when threads are terminated.
+
+=head1 ADDING NEW ERROR CODES TO OPENSSL
+
+See L<ERR_put_error(3)> if you want to record error codes in the
+OpenSSL error system from within your application.
+
+The remainder of this section is of interest only if you want to add
+new error codes to OpenSSL or add error codes from external libraries.
+
+=head2 Reporting errors
+
+Each sub-library has a specific macro XXXerr() that is used to report
+errors. Its first argument is a function code B<XXX_F_...>, the second
+argument is a reason code B<XXX_R_...>. Function codes are derived
+from the function names; reason codes consist of textual error
+descriptions. For example, the function ssl23_read() reports a
+"handshake failure" as follows:
+
+ SSLerr(SSL_F_SSL23_READ, SSL_R_SSL_HANDSHAKE_FAILURE);
+
+Function and reason codes should consist of upper case characters,
+numbers and underscores only. The error file generation script translates
+function codes into function names by looking in the header files
+for an appropriate function name, if none is found it just uses
+the capitalized form such as "SSL23_READ" in the above example.
+
+The trailing section of a reason code (after the "_R_") is translated
+into lower case and underscores changed to spaces.
+
+When you are using new function or reason codes, run B<make errors>.
+The necessary B<#define>s will then automatically be added to the
+sub-library's header file.
+
+Although a library will normally report errors using its own specific
+XXXerr macro, another library's macro can be used. This is normally
+only done when a library wants to include ASN1 code which must use
+the ASN1err() macro.
+
+=head2 Adding new libraries
+
+When adding a new sub-library to OpenSSL, assign it a library number
+B<ERR_LIB_XXX>, define a macro XXXerr() (both in B<err.h>), add its
+name to B<ERR_str_libraries[]> (in B<crypto/err/err.c>), and add
+C<ERR_load_XXX_strings()> to the ERR_load_crypto_strings() function
+(in B<crypto/err/err_all.c>). Finally, add an entry
+
+ L	XXX	xxx.h	xxx_err.c
+
+to B<crypto/err/openssl.ec>, and add B<xxx_err.c> to the Makefile.
+Running B<make errors> will then generate a file B<xxx_err.c>, and
+add all error codes used in the library to B<xxx.h>.
+
+Additionally the library include file must have a certain form.
+Typically it will initially look like this:
+
+ #ifndef HEADER_XXX_H
+ #define HEADER_XXX_H
+
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+
+ /* Include files */
+
+ #include <openssl/bio.h>
+ #include <openssl/x509.h>
+
+ /* Macros, structures and function prototypes */
+
+
+ /* BEGIN ERROR CODES */
+
+The B<BEGIN ERROR CODES> sequence is used by the error code
+generation script as the point to place new error codes, any text
+after this point will be overwritten when B<make errors> is run.
+The closing #endif etc will be automatically added by the script.
+
+The generated C error code file B<xxx_err.c> will load the header
+files B<stdio.h>, B<openssl/err.h> and B<openssl/xxx.h> so the
+header file must load any additional header files containing any
+definitions it uses.
+
+=head1 USING ERROR CODES IN EXTERNAL LIBRARIES
+
+It is also possible to use OpenSSL's error code scheme in external
+libraries. The library needs to load its own codes and call the OpenSSL
+error code insertion script B<mkerr.pl> explicitly to add codes to
+the header file and generate the C error code file. This will normally
+be done if the external library needs to generate new ASN1 structures
+but it can also be used to add more general purpose error code handling.
+
+TBA more details
+
+=head1 INTERNALS
+
+The error queues are stored in a hash table with one B<ERR_STATE>
+entry for each pid. ERR_get_state() returns the current thread's
+B<ERR_STATE>. An B<ERR_STATE> can hold up to B<ERR_NUM_ERRORS> error
+codes. When more error codes are added, the old ones are overwritten,
+on the assumption that the most recent errors are most important.
+
+Error strings are also stored in hash table. The hash tables can
+be obtained by calling ERR_get_err_state_table(void) and
+ERR_get_string_table(void) respectively.
+
+=head1 SEE ALSO
+
+L<CRYPTO_set_id_callback(3)|CRYPTO_set_id_callback(3)>,
+L<CRYPTO_set_locking_callback(3)|CRYPTO_set_locking_callback(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>,
+L<ERR_GET_LIB(3)|ERR_GET_LIB(3)>,
+L<ERR_clear_error(3)|ERR_clear_error(3)>,
+L<ERR_error_string(3)|ERR_error_string(3)>,
+L<ERR_print_errors(3)|ERR_print_errors(3)>,
+L<ERR_load_crypto_strings(3)|ERR_load_crypto_strings(3)>,
+L<ERR_remove_state(3)|ERR_remove_state(3)>,
+L<ERR_put_error(3)|ERR_put_error(3)>,
+L<ERR_load_strings(3)|ERR_load_strings(3)>,
+L<SSL_get_error(3)|SSL_get_error(3)>
+
+=cut
--- doc/crypto/openssl_rand.pod	1970-01-01 01:00:00.000000000 +0100
+++ doc/crypto/openssl_rand.pod	2010-04-01 00:45:01.059660101 +0200
@@ -0,0 +1,175 @@
+=pod
+
+=head1 NAME
+
+openssl_rand - pseudo-random number generator
+
+=head1 SYNOPSIS
+
+ #include <openssl/rand.h>
+
+ int  RAND_set_rand_engine(ENGINE *engine);
+
+ int  RAND_bytes(unsigned char *buf, int num);
+ int  RAND_pseudo_bytes(unsigned char *buf, int num);
+
+ void RAND_seed(const void *buf, int num);
+ void RAND_add(const void *buf, int num, int entropy);
+ int  RAND_status(void);
+
+ int  RAND_load_file(const char *file, long max_bytes);
+ int  RAND_write_file(const char *file);
+ const char *RAND_file_name(char *file, size_t num);
+
+ int  RAND_egd(const char *path);
+
+ void RAND_set_rand_method(const RAND_METHOD *meth);
+ const RAND_METHOD *RAND_get_rand_method(void);
+ RAND_METHOD *RAND_SSLeay(void);
+
+ void RAND_cleanup(void);
+
+ /* For Win32 only */
+ void RAND_screen(void);
+ int RAND_event(UINT, WPARAM, LPARAM);
+
+=head1 DESCRIPTION
+
+Since the introduction of the ENGINE API, the recommended way of controlling
+default implementations is by using the ENGINE API functions. The default
+B<RAND_METHOD>, as set by RAND_set_rand_method() and returned by
+RAND_get_rand_method(), is only used if no ENGINE has been set as the default
+"rand" implementation. Hence, these two functions are no longer the recommened
+way to control defaults.
+
+If an alternative B<RAND_METHOD> implementation is being used (either set
+directly or as provided by an ENGINE module), then it is entirely responsible
+for the generation and management of a cryptographically secure PRNG stream. The
+mechanisms described below relate solely to the software PRNG implementation
+built in to OpenSSL and used by default.
+
+These functions implement a cryptographically secure pseudo-random
+number generator (PRNG). It is used by other library functions for
+example to generate random keys, and applications can use it when they
+need randomness.
+
+A cryptographic PRNG must be seeded with unpredictable data such as
+mouse movements or keys pressed at random by the user. This is
+described in L<RAND_add(3)|RAND_add(3)>. Its state can be saved in a seed file
+(see L<RAND_load_file(3)|RAND_load_file(3)>) to avoid having to go through the
+seeding process whenever the application is started.
+
+L<RAND_bytes(3)|RAND_bytes(3)> describes how to obtain random data from the
+PRNG. 
+
+=head1 INTERNALS
+
+The RAND_SSLeay() method implements a PRNG based on a cryptographic
+hash function.
+
+The following description of its design is based on the SSLeay
+documentation:
+
+First up I will state the things I believe I need for a good RNG.
+
+=over 4
+
+=item 1
+
+A good hashing algorithm to mix things up and to convert the RNG 'state'
+to random numbers.
+
+=item 2
+
+An initial source of random 'state'.
+
+=item 3
+
+The state should be very large.  If the RNG is being used to generate
+4096 bit RSA keys, 2 2048 bit random strings are required (at a minimum).
+If your RNG state only has 128 bits, you are obviously limiting the
+search space to 128 bits, not 2048.  I'm probably getting a little
+carried away on this last point but it does indicate that it may not be
+a bad idea to keep quite a lot of RNG state.  It should be easier to
+break a cipher than guess the RNG seed data.
+
+=item 4
+
+Any RNG seed data should influence all subsequent random numbers
+generated.  This implies that any random seed data entered will have
+an influence on all subsequent random numbers generated.
+
+=item 5
+
+When using data to seed the RNG state, the data used should not be
+extractable from the RNG state.  I believe this should be a
+requirement because one possible source of 'secret' semi random
+data would be a private key or a password.  This data must
+not be disclosed by either subsequent random numbers or a
+'core' dump left by a program crash.
+
+=item 6
+
+Given the same initial 'state', 2 systems should deviate in their RNG state
+(and hence the random numbers generated) over time if at all possible.
+
+=item 7
+
+Given the random number output stream, it should not be possible to determine
+the RNG state or the next random number.
+
+=back
+
+The algorithm is as follows.
+
+There is global state made up of a 1023 byte buffer (the 'state'), a
+working hash value ('md'), and a counter ('count').
+
+Whenever seed data is added, it is inserted into the 'state' as
+follows.
+
+The input is chopped up into units of 20 bytes (or less for
+the last block).  Each of these blocks is run through the hash
+function as follows:  The data passed to the hash function
+is the current 'md', the same number of bytes from the 'state'
+(the location determined by in incremented looping index) as
+the current 'block', the new key data 'block', and 'count'
+(which is incremented after each use).
+The result of this is kept in 'md' and also xored into the
+'state' at the same locations that were used as input into the
+hash function. I
+believe this system addresses points 1 (hash function; currently
+SHA-1), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash
+function and xor).
+
+When bytes are extracted from the RNG, the following process is used.
+For each group of 10 bytes (or less), we do the following:
+
+Input into the hash function the local 'md' (which is initialized from
+the global 'md' before any bytes are generated), the bytes that are to
+be overwritten by the random bytes, and bytes from the 'state'
+(incrementing looping index). From this digest output (which is kept
+in 'md'), the top (up to) 10 bytes are returned to the caller and the
+bottom 10 bytes are xored into the 'state'.
+
+Finally, after we have finished 'num' random bytes for the caller,
+'count' (which is incremented) and the local and global 'md' are fed
+into the hash function and the results are kept in the global 'md'.
+
+I believe the above addressed points 1 (use of SHA-1), 6 (by hashing
+into the 'state' the 'old' data from the caller that is about to be
+overwritten) and 7 (by not using the 10 bytes given to the caller to
+update the 'state', but they are used to update 'md').
+
+So of the points raised, only 2 is not addressed (but see
+L<RAND_add(3)|RAND_add(3)>).
+
+=head1 SEE ALSO
+
+L<BN_rand(3)|BN_rand(3)>, L<RAND_add(3)|RAND_add(3)>,
+L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_egd(3)|RAND_egd(3)>,
+L<RAND_bytes(3)|RAND_bytes(3)>,
+L<RAND_set_rand_method(3)|RAND_set_rand_method(3)>,
+L<RAND_cleanup(3)|RAND_cleanup(3)> 
+
+=cut
--- doc/crypto/openssl_threads.pod	1970-01-01 01:00:00.000000000 +0100
+++ doc/crypto/openssl_threads.pod	2009-10-01 01:40:52.000000000 +0200
@@ -0,0 +1,210 @@
+=pod
+
+=head1 NAME
+
+CRYPTO_THREADID_set_callback, CRYPTO_THREADID_get_callback,
+CRYPTO_THREADID_current, CRYPTO_THREADID_cmp, CRYPTO_THREADID_cpy,
+CRYPTO_THREADID_hash, CRYPTO_set_locking_callback, CRYPTO_num_locks,
+CRYPTO_set_dynlock_create_callback, CRYPTO_set_dynlock_lock_callback,
+CRYPTO_set_dynlock_destroy_callback, CRYPTO_get_new_dynlockid,
+CRYPTO_destroy_dynlockid, CRYPTO_lock - OpenSSL thread support
+
+=head1 SYNOPSIS
+
+ #include <openssl/crypto.h>
+
+ /* Don't use this structure directly. */
+ typedef struct crypto_threadid_st
+         {
+         void *ptr;
+         unsigned long val;
+         } CRYPTO_THREADID;
+ /* Only use CRYPTO_THREADID_set_[numeric|pointer]() within callbacks */
+ void CRYPTO_THREADID_set_numeric(CRYPTO_THREADID *id, unsigned long val);
+ void CRYPTO_THREADID_set_pointer(CRYPTO_THREADID *id, void *ptr);
+ int CRYPTO_THREADID_set_callback(void (*threadid_func)(CRYPTO_THREADID *));
+ void (*CRYPTO_THREADID_get_callback(void))(CRYPTO_THREADID *);
+ void CRYPTO_THREADID_current(CRYPTO_THREADID *id);
+ int CRYPTO_THREADID_cmp(const CRYPTO_THREADID *a,
+                         const CRYPTO_THREADID *b);
+ void CRYPTO_THREADID_cpy(CRYPTO_THREADID *dest,
+                          const CRYPTO_THREADID *src);
+ unsigned long CRYPTO_THREADID_hash(const CRYPTO_THREADID *id);
+
+ int CRYPTO_num_locks(void);
+
+ /* struct CRYPTO_dynlock_value needs to be defined by the user */
+ struct CRYPTO_dynlock_value;
+
+ void CRYPTO_set_dynlock_create_callback(struct CRYPTO_dynlock_value *
+	(*dyn_create_function)(char *file, int line));
+ void CRYPTO_set_dynlock_lock_callback(void (*dyn_lock_function)
+	(int mode, struct CRYPTO_dynlock_value *l,
+	const char *file, int line));
+ void CRYPTO_set_dynlock_destroy_callback(void (*dyn_destroy_function)
+	(struct CRYPTO_dynlock_value *l, const char *file, int line));
+
+ int CRYPTO_get_new_dynlockid(void);
+
+ void CRYPTO_destroy_dynlockid(int i);
+
+ void CRYPTO_lock(int mode, int n, const char *file, int line);
+
+ #define CRYPTO_w_lock(type)	\
+	CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
+ #define CRYPTO_w_unlock(type)	\
+	CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
+ #define CRYPTO_r_lock(type)	\
+	CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,__FILE__,__LINE__)
+ #define CRYPTO_r_unlock(type)	\
+	CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,__FILE__,__LINE__)
+ #define CRYPTO_add(addr,amount,type)	\
+	CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__)
+
+=head1 DESCRIPTION
+
+OpenSSL can safely be used in multi-threaded applications provided
+that at least two callback functions are set, locking_function and
+threadid_func.
+
+locking_function(int mode, int n, const char *file, int line) is
+needed to perform locking on shared data structures. 
+(Note that OpenSSL uses a number of global data structures that
+will be implicitly shared whenever multiple threads use OpenSSL.)
+Multi-threaded applications will crash at random if it is not set.
+
+locking_function() must be able to handle up to CRYPTO_num_locks()
+different mutex locks. It sets the B<n>-th lock if B<mode> &
+B<CRYPTO_LOCK>, and releases it otherwise.
+
+B<file> and B<line> are the file number of the function setting the
+lock. They can be useful for debugging.
+
+threadid_func(CRYPTO_THREADID *id) is needed to record the currently-executing
+thread's identifier into B<id>. The implementation of this callback should not
+fill in B<id> directly, but should use CRYPTO_THREADID_set_numeric() if thread
+IDs are numeric, or CRYPTO_THREADID_set_pointer() if they are pointer-based.
+If the application does not register such a callback using
+CRYPTO_THREADID_set_callback(), then a default implementation is used - on
+Windows and BeOS this uses the system's default thread identifying APIs, and on
+all other platforms it uses the address of B<errno>. The latter is satisfactory
+for thread-safety if and only if the platform has a thread-local error number
+facility.
+
+Once threadid_func() is registered, or if the built-in default implementation is
+to be used;
+
+=over 4
+
+=item *
+CRYPTO_THREADID_current() records the currently-executing thread ID into the
+given B<id> object.
+
+=item *
+CRYPTO_THREADID_cmp() compares two thread IDs (returning zero for equality, ie.
+the same semantics as memcmp()).
+
+=item *
+CRYPTO_THREADID_cpy() duplicates a thread ID value,
+
+=item *
+CRYPTO_THREADID_hash() returns a numeric value usable as a hash-table key. This
+is usually the exact numeric or pointer-based thread ID used internally, however
+this also handles the unusual case where pointers are larger than 'long'
+variables and the platform's thread IDs are pointer-based - in this case, mixing
+is done to attempt to produce a unique numeric value even though it is not as
+wide as the platform's true thread IDs.
+
+=back
+
+Additionally, OpenSSL supports dynamic locks, and sometimes, some parts
+of OpenSSL need it for better performance.  To enable this, the following
+is required:
+
+=over 4
+
+=item *
+Three additional callback function, dyn_create_function, dyn_lock_function
+and dyn_destroy_function.
+
+=item *
+A structure defined with the data that each lock needs to handle.
+
+=back
+
+struct CRYPTO_dynlock_value has to be defined to contain whatever structure
+is needed to handle locks.
+
+dyn_create_function(const char *file, int line) is needed to create a
+lock.  Multi-threaded applications might crash at random if it is not set.
+
+dyn_lock_function(int mode, CRYPTO_dynlock *l, const char *file, int line)
+is needed to perform locking off dynamic lock numbered n. Multi-threaded
+applications might crash at random if it is not set.
+
+dyn_destroy_function(CRYPTO_dynlock *l, const char *file, int line) is
+needed to destroy the lock l. Multi-threaded applications might crash at
+random if it is not set.
+
+CRYPTO_get_new_dynlockid() is used to create locks.  It will call
+dyn_create_function for the actual creation.
+
+CRYPTO_destroy_dynlockid() is used to destroy locks.  It will call
+dyn_destroy_function for the actual destruction.
+
+CRYPTO_lock() is used to lock and unlock the locks.  mode is a bitfield
+describing what should be done with the lock.  n is the number of the
+lock as returned from CRYPTO_get_new_dynlockid().  mode can be combined
+from the following values.  These values are pairwise exclusive, with
+undefined behaviour if misused (for example, CRYPTO_READ and CRYPTO_WRITE
+should not be used together):
+
+	CRYPTO_LOCK	0x01
+	CRYPTO_UNLOCK	0x02
+	CRYPTO_READ	0x04
+	CRYPTO_WRITE	0x08
+
+=head1 RETURN VALUES
+
+CRYPTO_num_locks() returns the required number of locks.
+
+CRYPTO_get_new_dynlockid() returns the index to the newly created lock.
+
+The other functions return no values.
+
+=head1 NOTES
+
+You can find out if OpenSSL was configured with thread support:
+
+ #define OPENSSL_THREAD_DEFINES
+ #include <openssl/opensslconf.h>
+ #if defined(OPENSSL_THREADS)
+   // thread support enabled
+ #else
+   // no thread support
+ #endif
+
+Also, dynamic locks are currently not used internally by OpenSSL, but
+may do so in the future.
+
+=head1 EXAMPLES
+
+B<crypto/threads/mttest.c> shows examples of the callback functions on
+Solaris, Irix and Win32.
+
+=head1 HISTORY
+
+CRYPTO_set_locking_callback() is
+available in all versions of SSLeay and OpenSSL.
+CRYPTO_num_locks() was added in OpenSSL 0.9.4.
+All functions dealing with dynamic locks were added in OpenSSL 0.9.5b-dev.
+B<CRYPTO_THREADID> and associated functions were introduced in OpenSSL 1.0.0
+to replace (actually, deprecate) the previous CRYPTO_set_id_callback(),
+CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed
+thread IDs to always be represented by 'unsigned long'.
+
+=head1 SEE ALSO
+
+L<crypto(3)|crypto(3)>
+
+=cut
--- doc/crypto/RAND_add.pod	2000-03-22 16:30:03.000000000 +0100
+++ doc/crypto/RAND_add.pod	2010-04-01 00:45:00.939660251 +0200
@@ -65,7 +65,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<RAND_egd(3)|RAND_egd(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<RAND_egd(3)|RAND_egd(3)>,
 L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)>
 
 =head1 HISTORY
--- doc/crypto/RAND_bytes.pod	2007-09-24 13:01:18.000000000 +0200
+++ doc/crypto/RAND_bytes.pod	2010-04-01 00:45:00.946326823 +0200
@@ -38,7 +38,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
 L<RAND_add(3)|RAND_add(3)>
 
 =head1 HISTORY
--- doc/crypto/RAND_cleanup.pod	2000-01-27 02:25:06.000000000 +0100
+++ doc/crypto/RAND_cleanup.pod	2010-04-01 00:45:00.952993593 +0200
@@ -20,7 +20,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>
+L<openssl_rand(3)|openssl_rand(3)>
 
 =head1 HISTORY
 
--- doc/crypto/RAND_egd.pod	2008-11-10 12:26:44.000000000 +0100
+++ doc/crypto/RAND_egd.pod	2010-04-01 00:45:00.959660646 +0200
@@ -72,7 +72,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<RAND_add(3)|RAND_add(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<RAND_add(3)|RAND_add(3)>,
 L<RAND_cleanup(3)|RAND_cleanup(3)>
 
 =head1 HISTORY
--- doc/crypto/RAND_load_file.pod	2001-03-21 16:25:56.000000000 +0100
+++ doc/crypto/RAND_load_file.pod	2010-04-01 00:45:00.976327494 +0200
@@ -43,7 +43,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<RAND_add(3)|RAND_add(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)>
+L<openssl_rand(3)|openssl_rand(3)>, L<RAND_add(3)|RAND_add(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)>
 
 =head1 HISTORY
 
--- doc/crypto/rand.pod	2002-08-05 18:27:01.000000000 +0200
+++ doc/crypto/rand.pod	1970-01-01 01:00:00.000000000 +0100
@@ -1,175 +0,0 @@
-=pod
-
-=head1 NAME
-
-rand - pseudo-random number generator
-
-=head1 SYNOPSIS
-
- #include <openssl/rand.h>
-
- int  RAND_set_rand_engine(ENGINE *engine);
-
- int  RAND_bytes(unsigned char *buf, int num);
- int  RAND_pseudo_bytes(unsigned char *buf, int num);
-
- void RAND_seed(const void *buf, int num);
- void RAND_add(const void *buf, int num, int entropy);
- int  RAND_status(void);
-
- int  RAND_load_file(const char *file, long max_bytes);
- int  RAND_write_file(const char *file);
- const char *RAND_file_name(char *file, size_t num);
-
- int  RAND_egd(const char *path);
-
- void RAND_set_rand_method(const RAND_METHOD *meth);
- const RAND_METHOD *RAND_get_rand_method(void);
- RAND_METHOD *RAND_SSLeay(void);
-
- void RAND_cleanup(void);
-
- /* For Win32 only */
- void RAND_screen(void);
- int RAND_event(UINT, WPARAM, LPARAM);
-
-=head1 DESCRIPTION
-
-Since the introduction of the ENGINE API, the recommended way of controlling
-default implementations is by using the ENGINE API functions. The default
-B<RAND_METHOD>, as set by RAND_set_rand_method() and returned by
-RAND_get_rand_method(), is only used if no ENGINE has been set as the default
-"rand" implementation. Hence, these two functions are no longer the recommened
-way to control defaults.
-
-If an alternative B<RAND_METHOD> implementation is being used (either set
-directly or as provided by an ENGINE module), then it is entirely responsible
-for the generation and management of a cryptographically secure PRNG stream. The
-mechanisms described below relate solely to the software PRNG implementation
-built in to OpenSSL and used by default.
-
-These functions implement a cryptographically secure pseudo-random
-number generator (PRNG). It is used by other library functions for
-example to generate random keys, and applications can use it when they
-need randomness.
-
-A cryptographic PRNG must be seeded with unpredictable data such as
-mouse movements or keys pressed at random by the user. This is
-described in L<RAND_add(3)|RAND_add(3)>. Its state can be saved in a seed file
-(see L<RAND_load_file(3)|RAND_load_file(3)>) to avoid having to go through the
-seeding process whenever the application is started.
-
-L<RAND_bytes(3)|RAND_bytes(3)> describes how to obtain random data from the
-PRNG. 
-
-=head1 INTERNALS
-
-The RAND_SSLeay() method implements a PRNG based on a cryptographic
-hash function.
-
-The following description of its design is based on the SSLeay
-documentation:
-
-First up I will state the things I believe I need for a good RNG.
-
-=over 4
-
-=item 1
-
-A good hashing algorithm to mix things up and to convert the RNG 'state'
-to random numbers.
-
-=item 2
-
-An initial source of random 'state'.
-
-=item 3
-
-The state should be very large.  If the RNG is being used to generate
-4096 bit RSA keys, 2 2048 bit random strings are required (at a minimum).
-If your RNG state only has 128 bits, you are obviously limiting the
-search space to 128 bits, not 2048.  I'm probably getting a little
-carried away on this last point but it does indicate that it may not be
-a bad idea to keep quite a lot of RNG state.  It should be easier to
-break a cipher than guess the RNG seed data.
-
-=item 4
-
-Any RNG seed data should influence all subsequent random numbers
-generated.  This implies that any random seed data entered will have
-an influence on all subsequent random numbers generated.
-
-=item 5
-
-When using data to seed the RNG state, the data used should not be
-extractable from the RNG state.  I believe this should be a
-requirement because one possible source of 'secret' semi random
-data would be a private key or a password.  This data must
-not be disclosed by either subsequent random numbers or a
-'core' dump left by a program crash.
-
-=item 6
-
-Given the same initial 'state', 2 systems should deviate in their RNG state
-(and hence the random numbers generated) over time if at all possible.
-
-=item 7
-
-Given the random number output stream, it should not be possible to determine
-the RNG state or the next random number.
-
-=back
-
-The algorithm is as follows.
-
-There is global state made up of a 1023 byte buffer (the 'state'), a
-working hash value ('md'), and a counter ('count').
-
-Whenever seed data is added, it is inserted into the 'state' as
-follows.
-
-The input is chopped up into units of 20 bytes (or less for
-the last block).  Each of these blocks is run through the hash
-function as follows:  The data passed to the hash function
-is the current 'md', the same number of bytes from the 'state'
-(the location determined by in incremented looping index) as
-the current 'block', the new key data 'block', and 'count'
-(which is incremented after each use).
-The result of this is kept in 'md' and also xored into the
-'state' at the same locations that were used as input into the
-hash function. I
-believe this system addresses points 1 (hash function; currently
-SHA-1), 3 (the 'state'), 4 (via the 'md'), 5 (by the use of a hash
-function and xor).
-
-When bytes are extracted from the RNG, the following process is used.
-For each group of 10 bytes (or less), we do the following:
-
-Input into the hash function the local 'md' (which is initialized from
-the global 'md' before any bytes are generated), the bytes that are to
-be overwritten by the random bytes, and bytes from the 'state'
-(incrementing looping index). From this digest output (which is kept
-in 'md'), the top (up to) 10 bytes are returned to the caller and the
-bottom 10 bytes are xored into the 'state'.
-
-Finally, after we have finished 'num' random bytes for the caller,
-'count' (which is incremented) and the local and global 'md' are fed
-into the hash function and the results are kept in the global 'md'.
-
-I believe the above addressed points 1 (use of SHA-1), 6 (by hashing
-into the 'state' the 'old' data from the caller that is about to be
-overwritten) and 7 (by not using the 10 bytes given to the caller to
-update the 'state', but they are used to update 'md').
-
-So of the points raised, only 2 is not addressed (but see
-L<RAND_add(3)|RAND_add(3)>).
-
-=head1 SEE ALSO
-
-L<BN_rand(3)|BN_rand(3)>, L<RAND_add(3)|RAND_add(3)>,
-L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_egd(3)|RAND_egd(3)>,
-L<RAND_bytes(3)|RAND_bytes(3)>,
-L<RAND_set_rand_method(3)|RAND_set_rand_method(3)>,
-L<RAND_cleanup(3)|RAND_cleanup(3)> 
-
-=cut
--- doc/crypto/RAND_set_rand_method.pod	2007-11-19 10:18:03.000000000 +0100
+++ doc/crypto/RAND_set_rand_method.pod	2010-04-01 00:45:00.982994946 +0200
@@ -67,7 +67,7 @@
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<engine(3)|engine(3)>
+L<openssl_rand(3)|openssl_rand(3)>, L<engine(3)|engine(3)>
 
 =head1 HISTORY
 
--- doc/crypto/RSA_blinding_on.pod	2000-02-24 12:55:10.000000000 +0100
+++ doc/crypto/RSA_blinding_on.pod	2010-04-01 00:45:00.989661318 +0200
@@ -34,7 +34,7 @@
 
 =head1 SEE ALSO
 
-L<rsa(3)|rsa(3)>, L<rand(3)|rand(3)>
+L<rsa(3)|rsa(3)>, L<openssl_rand(3)|openssl_rand(3)>
 
 =head1 HISTORY
 
--- doc/crypto/RSA_generate_key.pod	2002-09-25 15:33:27.000000000 +0200
+++ doc/crypto/RSA_generate_key.pod	2010-04-01 00:45:00.996327969 +0200
@@ -59,7 +59,7 @@
 
 =head1 SEE ALSO
 
-L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>, L<rsa(3)|rsa(3)>,
 L<RSA_free(3)|RSA_free(3)>
 
 =head1 HISTORY
--- doc/crypto/rsa.pod	2002-08-04 23:08:36.000000000 +0200
+++ doc/crypto/rsa.pod	2010-04-01 00:45:01.062995006 +0200
@@ -108,7 +108,7 @@
 =head1 SEE ALSO
 
 L<rsa(1)|rsa(1)>, L<bn(3)|bn(3)>, L<dsa(3)|dsa(3)>, L<dh(3)|dh(3)>,
-L<rand(3)|rand(3)>, L<engine(3)|engine(3)>, L<RSA_new(3)|RSA_new(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<engine(3)|engine(3)>, L<RSA_new(3)|RSA_new(3)>,
 L<RSA_public_encrypt(3)|RSA_public_encrypt(3)>,
 L<RSA_sign(3)|RSA_sign(3)>, L<RSA_size(3)|RSA_size(3)>,
 L<RSA_generate_key(3)|RSA_generate_key(3)>,
--- doc/crypto/RSA_public_encrypt.pod	2004-03-23 22:01:34.000000000 +0100
+++ doc/crypto/RSA_public_encrypt.pod	2010-04-01 00:45:01.002994781 +0200
@@ -73,7 +73,7 @@
 
 =head1 SEE ALSO
 
-L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>, L<openssl_rand(3)|openssl_rand(3)>, L<rsa(3)|rsa(3)>,
 L<RSA_size(3)|RSA_size(3)>
 
 =head1 HISTORY
--- doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod	2002-09-25 15:33:28.000000000 +0200
+++ doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod	2010-04-01 00:45:01.009660553 +0200
@@ -48,7 +48,7 @@
 =head1 SEE ALSO
 
 L<ERR_get_error(3)|ERR_get_error(3)>, L<objects(3)|objects(3)>,
-L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_sign(3)|RSA_sign(3)>,
+L<openssl_rand(3)|openssl_rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_sign(3)|RSA_sign(3)>,
 L<RSA_verify(3)|RSA_verify(3)>
 
 =head1 HISTORY
--- doc/crypto/threads.pod	2009-10-01 01:40:52.000000000 +0200
+++ doc/crypto/threads.pod	1970-01-01 01:00:00.000000000 +0100
@@ -1,210 +0,0 @@
-=pod
-
-=head1 NAME
-
-CRYPTO_THREADID_set_callback, CRYPTO_THREADID_get_callback,
-CRYPTO_THREADID_current, CRYPTO_THREADID_cmp, CRYPTO_THREADID_cpy,
-CRYPTO_THREADID_hash, CRYPTO_set_locking_callback, CRYPTO_num_locks,
-CRYPTO_set_dynlock_create_callback, CRYPTO_set_dynlock_lock_callback,
-CRYPTO_set_dynlock_destroy_callback, CRYPTO_get_new_dynlockid,
-CRYPTO_destroy_dynlockid, CRYPTO_lock - OpenSSL thread support
-
-=head1 SYNOPSIS
-
- #include <openssl/crypto.h>
-
- /* Don't use this structure directly. */
- typedef struct crypto_threadid_st
-         {
-         void *ptr;
-         unsigned long val;
-         } CRYPTO_THREADID;
- /* Only use CRYPTO_THREADID_set_[numeric|pointer]() within callbacks */
- void CRYPTO_THREADID_set_numeric(CRYPTO_THREADID *id, unsigned long val);
- void CRYPTO_THREADID_set_pointer(CRYPTO_THREADID *id, void *ptr);
- int CRYPTO_THREADID_set_callback(void (*threadid_func)(CRYPTO_THREADID *));
- void (*CRYPTO_THREADID_get_callback(void))(CRYPTO_THREADID *);
- void CRYPTO_THREADID_current(CRYPTO_THREADID *id);
- int CRYPTO_THREADID_cmp(const CRYPTO_THREADID *a,
-                         const CRYPTO_THREADID *b);
- void CRYPTO_THREADID_cpy(CRYPTO_THREADID *dest,
-                          const CRYPTO_THREADID *src);
- unsigned long CRYPTO_THREADID_hash(const CRYPTO_THREADID *id);
-
- int CRYPTO_num_locks(void);
-
- /* struct CRYPTO_dynlock_value needs to be defined by the user */
- struct CRYPTO_dynlock_value;
-
- void CRYPTO_set_dynlock_create_callback(struct CRYPTO_dynlock_value *
-	(*dyn_create_function)(char *file, int line));
- void CRYPTO_set_dynlock_lock_callback(void (*dyn_lock_function)
-	(int mode, struct CRYPTO_dynlock_value *l,
-	const char *file, int line));
- void CRYPTO_set_dynlock_destroy_callback(void (*dyn_destroy_function)
-	(struct CRYPTO_dynlock_value *l, const char *file, int line));
-
- int CRYPTO_get_new_dynlockid(void);
-
- void CRYPTO_destroy_dynlockid(int i);
-
- void CRYPTO_lock(int mode, int n, const char *file, int line);
-
- #define CRYPTO_w_lock(type)	\
-	CRYPTO_lock(CRYPTO_LOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
- #define CRYPTO_w_unlock(type)	\
-	CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_WRITE,type,__FILE__,__LINE__)
- #define CRYPTO_r_lock(type)	\
-	CRYPTO_lock(CRYPTO_LOCK|CRYPTO_READ,type,__FILE__,__LINE__)
- #define CRYPTO_r_unlock(type)	\
-	CRYPTO_lock(CRYPTO_UNLOCK|CRYPTO_READ,type,__FILE__,__LINE__)
- #define CRYPTO_add(addr,amount,type)	\
-	CRYPTO_add_lock(addr,amount,type,__FILE__,__LINE__)
-
-=head1 DESCRIPTION
-
-OpenSSL can safely be used in multi-threaded applications provided
-that at least two callback functions are set, locking_function and
-threadid_func.
-
-locking_function(int mode, int n, const char *file, int line) is
-needed to perform locking on shared data structures. 
-(Note that OpenSSL uses a number of global data structures that
-will be implicitly shared whenever multiple threads use OpenSSL.)
-Multi-threaded applications will crash at random if it is not set.
-
-locking_function() must be able to handle up to CRYPTO_num_locks()
-different mutex locks. It sets the B<n>-th lock if B<mode> &
-B<CRYPTO_LOCK>, and releases it otherwise.
-
-B<file> and B<line> are the file number of the function setting the
-lock. They can be useful for debugging.
-
-threadid_func(CRYPTO_THREADID *id) is needed to record the currently-executing
-thread's identifier into B<id>. The implementation of this callback should not
-fill in B<id> directly, but should use CRYPTO_THREADID_set_numeric() if thread
-IDs are numeric, or CRYPTO_THREADID_set_pointer() if they are pointer-based.
-If the application does not register such a callback using
-CRYPTO_THREADID_set_callback(), then a default implementation is used - on
-Windows and BeOS this uses the system's default thread identifying APIs, and on
-all other platforms it uses the address of B<errno>. The latter is satisfactory
-for thread-safety if and only if the platform has a thread-local error number
-facility.
-
-Once threadid_func() is registered, or if the built-in default implementation is
-to be used;
-
-=over 4
-
-=item *
-CRYPTO_THREADID_current() records the currently-executing thread ID into the
-given B<id> object.
-
-=item *
-CRYPTO_THREADID_cmp() compares two thread IDs (returning zero for equality, ie.
-the same semantics as memcmp()).
-
-=item *
-CRYPTO_THREADID_cpy() duplicates a thread ID value,
-
-=item *
-CRYPTO_THREADID_hash() returns a numeric value usable as a hash-table key. This
-is usually the exact numeric or pointer-based thread ID used internally, however
-this also handles the unusual case where pointers are larger than 'long'
-variables and the platform's thread IDs are pointer-based - in this case, mixing
-is done to attempt to produce a unique numeric value even though it is not as
-wide as the platform's true thread IDs.
-
-=back
-
-Additionally, OpenSSL supports dynamic locks, and sometimes, some parts
-of OpenSSL need it for better performance.  To enable this, the following
-is required:
-
-=over 4
-
-=item *
-Three additional callback function, dyn_create_function, dyn_lock_function
-and dyn_destroy_function.
-
-=item *
-A structure defined with the data that each lock needs to handle.
-
-=back
-
-struct CRYPTO_dynlock_value has to be defined to contain whatever structure
-is needed to handle locks.
-
-dyn_create_function(const char *file, int line) is needed to create a
-lock.  Multi-threaded applications might crash at random if it is not set.
-
-dyn_lock_function(int mode, CRYPTO_dynlock *l, const char *file, int line)
-is needed to perform locking off dynamic lock numbered n. Multi-threaded
-applications might crash at random if it is not set.
-
-dyn_destroy_function(CRYPTO_dynlock *l, const char *file, int line) is
-needed to destroy the lock l. Multi-threaded applications might crash at
-random if it is not set.
-
-CRYPTO_get_new_dynlockid() is used to create locks.  It will call
-dyn_create_function for the actual creation.
-
-CRYPTO_destroy_dynlockid() is used to destroy locks.  It will call
-dyn_destroy_function for the actual destruction.
-
-CRYPTO_lock() is used to lock and unlock the locks.  mode is a bitfield
-describing what should be done with the lock.  n is the number of the
-lock as returned from CRYPTO_get_new_dynlockid().  mode can be combined
-from the following values.  These values are pairwise exclusive, with
-undefined behaviour if misused (for example, CRYPTO_READ and CRYPTO_WRITE
-should not be used together):
-
-	CRYPTO_LOCK	0x01
-	CRYPTO_UNLOCK	0x02
-	CRYPTO_READ	0x04
-	CRYPTO_WRITE	0x08
-
-=head1 RETURN VALUES
-
-CRYPTO_num_locks() returns the required number of locks.
-
-CRYPTO_get_new_dynlockid() returns the index to the newly created lock.
-
-The other functions return no values.
-
-=head1 NOTES
-
-You can find out if OpenSSL was configured with thread support:
-
- #define OPENSSL_THREAD_DEFINES
- #include <openssl/opensslconf.h>
- #if defined(OPENSSL_THREADS)
-   // thread support enabled
- #else
-   // no thread support
- #endif
-
-Also, dynamic locks are currently not used internally by OpenSSL, but
-may do so in the future.
-
-=head1 EXAMPLES
-
-B<crypto/threads/mttest.c> shows examples of the callback functions on
-Solaris, Irix and Win32.
-
-=head1 HISTORY
-
-CRYPTO_set_locking_callback() is
-available in all versions of SSLeay and OpenSSL.
-CRYPTO_num_locks() was added in OpenSSL 0.9.4.
-All functions dealing with dynamic locks were added in OpenSSL 0.9.5b-dev.
-B<CRYPTO_THREADID> and associated functions were introduced in OpenSSL 1.0.0
-to replace (actually, deprecate) the previous CRYPTO_set_id_callback(),
-CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed
-thread IDs to always be represented by 'unsigned long'.
-
-=head1 SEE ALSO
-
-L<crypto(3)|crypto(3)>
-
-=cut
--- doc/crypto/X509_NAME_ENTRY_get_object.pod	2006-05-14 13:27:59.000000000 +0200
+++ doc/crypto/X509_NAME_ENTRY_get_object.pod	2010-04-01 00:45:01.016327524 +0200
@@ -65,7 +65,7 @@
 =head1 SEE ALSO
 
 L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_X509_NAME(3)|d2i_X509_NAME(3)>,
-L<OBJ_nid2obj(3),OBJ_nid2obj(3)>
+L<OBJ_nid2obj(3)|OBJ_nid2obj(3)>
 
 =head1 HISTORY
 
--- doc/ssl/SSL_get_error.pod	2005-03-30 13:50:14.000000000 +0200
+++ doc/ssl/SSL_get_error.pod	2010-04-01 00:45:03.069662282 +0200
@@ -105,7 +105,7 @@
 
 =head1 SEE ALSO
 
-L<ssl(3)|ssl(3)>, L<err(3)|err(3)>
+L<ssl(3)|ssl(3)>, L<openssl_err(3)|openssl_err(3)>
 
 =head1 HISTORY
 
--- doc/ssl/SSL_want.pod	2005-03-30 13:50:14.000000000 +0200
+++ doc/ssl/SSL_want.pod	2010-04-01 00:45:03.082993225 +0200
@@ -72,6 +72,6 @@
 
 =head1 SEE ALSO
 
-L<ssl(3)|ssl(3)>, L<err(3)|err(3)>, L<SSL_get_error(3)|SSL_get_error(3)>
+L<ssl(3)|ssl(3)>, L<openssl_err(3)|openssl_err(3)>, L<SSL_get_error(3)|SSL_get_error(3)>
 
 =cut
--- FAQ	2010-03-29 15:11:53.000000000 +0200
+++ FAQ	2010-04-01 00:46:00.593821225 +0200
@@ -724,7 +724,7 @@
 CRYPTO_set_id_callback(), for all versions of OpenSSL up to and
 including 0.9.8[abc...]. As of version 0.9.9, CRYPTO_set_id_callback()
 and associated APIs are deprecated by CRYPTO_THREADID_set_callback()
-and friends. This is described in the threads(3) manpage.
+and friends. This is described in the openssl_threads(3) manpage.
 
 * I've compiled a program under Windows and it crashes: why?