--- 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?