summaryrefslogtreecommitdiffstats
path: root/abs/core-testing/openssl/fix-manpages.patch
diff options
context:
space:
mode:
authorJames Meyer <james.meyer@operamail.com>2010-09-08 07:33:44 (GMT)
committerJames Meyer <james.meyer@operamail.com>2010-09-08 07:33:44 (GMT)
commit525753e4a1a139e088d8ac120b19fbab6c0aaaa6 (patch)
tree35cef28abb613da4f58e83f6abbe4bd4cfa244bf /abs/core-testing/openssl/fix-manpages.patch
parent592e3cad43ef12c53f523145d0fd981b54f2a049 (diff)
parentb172f79fadb565ecfbcec9508f9377d8618a4f4c (diff)
downloadlinhes_pkgbuild-525753e4a1a139e088d8ac120b19fbab6c0aaaa6.zip
linhes_pkgbuild-525753e4a1a139e088d8ac120b19fbab6c0aaaa6.tar.gz
linhes_pkgbuild-525753e4a1a139e088d8ac120b19fbab6c0aaaa6.tar.bz2
Merge branch 'HEAD' of ssh://jams@knoppmyth.net/mount/repository/LinHES-PKGBUILD
Diffstat (limited to 'abs/core-testing/openssl/fix-manpages.patch')
-rw-r--r--abs/core-testing/openssl/fix-manpages.patch1887
1 files changed, 1887 insertions, 0 deletions
diff --git a/abs/core-testing/openssl/fix-manpages.patch b/abs/core-testing/openssl/fix-manpages.patch
new file mode 100644
index 0000000..e043081
--- /dev/null
+++ b/abs/core-testing/openssl/fix-manpages.patch
@@ -0,0 +1,1887 @@
+--- 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?
+