diff options
Diffstat (limited to 'abs/core-testing/openssl/fix-manpages.patch')
| -rw-r--r-- | abs/core-testing/openssl/fix-manpages.patch | 1887 |
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? + |