13 files changed, 51 insertions, 46 deletions
diff --git a/doc/crypto/BIO_read.pod b/doc/crypto/BIO_read.pod
index b345281..2c177f0 100644
--- a/doc/crypto/BIO_read.pod
+++ b/doc/crypto/BIO_read.pod
@@ -9,9 +9,9 @@ BIO_read, BIO_write, BIO_gets, BIO_puts - BIO I/O functions
  #include <openssl/bio.h>
 
  int	BIO_read(BIO *b, void *buf, int len);
- int	BIO_gets(BIO *b,char *buf, int size);
+ int	BIO_gets(BIO *b, char *buf, int size);
  int	BIO_write(BIO *b, const void *buf, int len);
- int	BIO_puts(BIO *b,const char *buf);
+ int	BIO_puts(BIO *b, const char *buf);
 
 =head1 DESCRIPTION
 
@@ -26,7 +26,7 @@ return the digest and other BIOs may not support BIO_gets() at all.
 
 BIO_write() attempts to write B<len> bytes from B<buf> to BIO B<b>.
 
-BIO_puts() attempts to write a null terminated string B<buf> to BIO B<b>
+BIO_puts() attempts to write a null terminated string B<buf> to BIO B<b>.
 
 =head1 RETURN VALUES
 
diff --git a/doc/crypto/BN_rand.pod b/doc/crypto/BN_rand.pod
index bd6bc86..e8cbf65 100644
--- a/doc/crypto/BN_rand.pod
+++ b/doc/crypto/BN_rand.pod
@@ -19,7 +19,7 @@ BN_rand, BN_pseudo_rand, BN_rand_range, BN_pseudo_rand_range - generate pseudo-r
 =head1 DESCRIPTION
 
 BN_rand() generates a cryptographically strong pseudo-random number of
-B<bits> bits in length and stores it in B<rnd>. If B<top> is -1, the
+B<bits> in length and stores it in B<rnd>. If B<top> is -1, the
 most significant bit of the random number can be zero. If B<top> is 0,
 it is set to 1, and if B<top> is 1, the two most significant bits of
 the number will be set to 1, so that the product of two such random
@@ -33,7 +33,7 @@ non-cryptographic purposes and for certain purposes in cryptographic
 protocols, but usually not for key generation etc.
 
 BN_rand_range() generates a cryptographically strong pseudo-random
-number B<rnd> in the range 0 <lt>= B<rnd> E<lt> B<range>.
+number B<rnd> in the range 0 E<lt>= B<rnd> E<lt> B<range>.
 BN_pseudo_rand_range() does the same, but is based on BN_pseudo_rand(),
 and hence numbers generated by it are not necessarily unpredictable.
 
diff --git a/doc/crypto/DSA_generate_parameters.pod b/doc/crypto/DSA_generate_parameters.pod
index 16a67f2..b1a4d20 100644
--- a/doc/crypto/DSA_generate_parameters.pod
+++ b/doc/crypto/DSA_generate_parameters.pod
@@ -29,7 +29,7 @@ maximum of 1024 bits.
 If B<seed> is B<NULL> or B<seed_len> E<lt> 20, the primes will be
 generated at random. Otherwise, the seed is used to generate
 them. If the given seed does not yield a prime q, a new random
-seed is chosen and placed at B<seed>.
+seed is chosen.
 
 DSA_generate_parameters_ex() places the iteration count in
 *B<counter_ret> and a counter used for finding a generator in
diff --git a/doc/crypto/EC_GROUP_copy.pod b/doc/crypto/EC_GROUP_copy.pod
index 954af46..49dc01c 100644
--- a/doc/crypto/EC_GROUP_copy.pod
+++ b/doc/crypto/EC_GROUP_copy.pod
@@ -158,7 +158,7 @@ EC_GROUP_get0_seed returns a pointer to the seed that was used to generate the p
 specified. EC_GROUP_get_seed_len returns the length of the seed or 0 if the seed is not specified.
 
 EC_GROUP_set_seed returns the length of the seed that has been set. If the supplied seed is NULL, or the supplied seed length is
-0, the the return value will be 1. On error 0 is returned.
+0, the return value will be 1. On error 0 is returned.
 
 EC_GROUP_cmp returns 0 if the curves are equal, 1 if they are not equal, or -1 on error.
 
diff --git a/doc/crypto/EC_KEY_new.pod b/doc/crypto/EC_KEY_new.pod
index e859689..0fa2de1 100644
--- a/doc/crypto/EC_KEY_new.pod
+++ b/doc/crypto/EC_KEY_new.pod
@@ -70,8 +70,8 @@ The functions EC_KEY_get0_group, EC_KEY_set_group, EC_KEY_get0_private_key, EC_K
 The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B<key>. For a description
 of point_conversion_forms please refer to L<EC_POINT_new(3)|EC_POINT_new(3)>.
 
-EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the
-elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
+EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the
+elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
 
 EC_KEY_set_flags sets the flags in the B<flags> parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B<flags> parameter. All other flags are left in their existing state.
 
diff --git a/doc/crypto/EVP_DigestVerifyInit.pod b/doc/crypto/EVP_DigestVerifyInit.pod
index e0217e4..0ead2d2 100644
--- a/doc/crypto/EVP_DigestVerifyInit.pod
+++ b/doc/crypto/EVP_DigestVerifyInit.pod
@@ -37,10 +37,11 @@ EVP_DigestVerifyInit() and EVP_DigestVerifyUpdate() return 1 for success and 0
 or a negative value for failure. In particular a return value of -2 indicates
 the operation is not supported by the public key algorithm.
 
-Unlike other functions the return value 0 from EVP_DigestVerifyFinal() only
-indicates that the signature did not verify successfully (that is tbs did
-not match the original data or the signature was of invalid form) it is not an
-indication of a more serious error.
+EVP_DigestVerifyFinal() returns 1 for success; any other value indicates
+failure.  A return value of zero indicates that the signature did not verify
+successfully (that is, tbs did not match the original data or the signature had
+an invalid form), while other values indicate a more serious error (and
+sometimes also indicate an invalid signature form).
 
 The error codes can be obtained from L<ERR_get_error(3)|ERR_get_error(3)>.
 
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index fb6036f..c69e6a6 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++ b/doc/crypto/EVP_EncryptInit.pod
@@ -111,7 +111,7 @@ EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
 EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
 with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
 before calling this function. B<type> is normally supplied
-by a function such as EVP_des_cbc(). If B<impl> is NULL then the
+by a function such as EVP_aes_256_cbc(). If B<impl> is NULL then the
 default implementation is used. B<key> is the symmetric key to use
 and B<iv> is the IV to use (if necessary), the actual number of bytes
 used for the key and IV depends on the cipher. It is possible to set
diff --git a/doc/crypto/EVP_SealInit.pod b/doc/crypto/EVP_SealInit.pod
index 7d793e1..19112a5 100644
--- a/doc/crypto/EVP_SealInit.pod
+++ b/doc/crypto/EVP_SealInit.pod
@@ -25,7 +25,7 @@ encrypted using this key.
 
 EVP_SealInit() initializes a cipher context B<ctx> for encryption
 with cipher B<type> using a random secret key and IV. B<type> is normally
-supplied by a function such as EVP_des_cbc(). The secret key is encrypted
+supplied by a function such as EVP_aes_256_cbc(). The secret key is encrypted
 using one or more public keys, this allows the same encrypted data to be
 decrypted using any of the corresponding private keys. B<ek> is an array of
 buffers where the public key encrypted secret key will be written, each buffer
diff --git a/doc/crypto/EVP_SignInit.pod b/doc/crypto/EVP_SignInit.pod
index 14ecc77..c63d6b3 100644
--- a/doc/crypto/EVP_SignInit.pod
+++ b/doc/crypto/EVP_SignInit.pod
@@ -2,7 +2,8 @@
 
 =head1 NAME
 
-EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
+EVP_SignInit, EVP_SignInit_ex, EVP_SignUpdate, EVP_SignFinal - EVP signing
+functions
 
 =head1 SYNOPSIS
 
diff --git a/doc/crypto/X509_check_host.pod b/doc/crypto/X509_check_host.pod
index 0def17a..521b9f5 100644
--- a/doc/crypto/X509_check_host.pod
+++ b/doc/crypto/X509_check_host.pod
@@ -135,6 +135,6 @@ L<X509_VERIFY_PARAM_set1_ipasc(3)|X509_VERIFY_PARAM_set1_ipasc(3)>
 
 =head1 HISTORY
 
-These functions were added in OpenSSL 1.1.0.
+These functions were added in OpenSSL 1.0.2.
 
 =cut
diff --git a/doc/crypto/buffer.pod b/doc/crypto/buffer.pod
index 781f5b1..52c5c84 100644
--- a/doc/crypto/buffer.pod
+++ b/doc/crypto/buffer.pod
@@ -2,8 +2,11 @@
 
 =head1 NAME
 
-BUF_MEM_new, BUF_MEM_free, BUF_MEM_grow, BUF_strdup - simple
-character arrays structure
+BUF_MEM_new, BUF_MEM_new_ex, BUF_MEM_free, BUF_MEM_grow - simple
+character array structure
+
+BUF_strdup, BUF_strndup, BUF_memdup, BUF_strlcpy, BUF_strlcat -
+standard C library equivalents
 
 =head1 SYNOPSIS
 
@@ -15,25 +18,22 @@ character arrays structure
 
  int	BUF_MEM_grow(BUF_MEM *str, int len);
 
- char *	BUF_strdup(const char *str);
+ char *BUF_strdup(const char *str);
 
-=head1 DESCRIPTION
+ char *BUF_strndup(const char *str, size_t siz);
 
-The buffer library handles simple character arrays. Buffers are used for
-various purposes in the library, most notably memory BIOs.
+ void *BUF_memdup(const void *data, size_t siz);
+
+ size_t BUF_strlcpy(char *dst, const char *src, size_t size);
 
-The library uses the BUF_MEM structure defined in buffer.h:
+ size_t BUF_strlcat(char *dst, const char *src, size_t size);
 
- typedef struct buf_mem_st
- {
-        int length;     /* current number of bytes */
-        char *data;
-        int max;        /* size of buffer */
- } BUF_MEM;
+ size_t BUF_strnlen(const char *str, size_t maxlen);
 
-B<length> is the current size of the buffer in bytes, B<max> is the amount of
-memory allocated to the buffer. There are three functions which handle these
-and one "miscellaneous" function.
+=head1 DESCRIPTION
+
+The buffer library handles simple character arrays. Buffers are used for
+various purposes in the library, most notably memory BIOs.
 
 BUF_MEM_new() allocates a new buffer of zero size.
 
@@ -44,14 +44,17 @@ BUF_MEM_grow() changes the size of an already existing buffer to
 B<len>. Any data already in the buffer is preserved if it increases in
 size.
 
-BUF_strdup() copies a null terminated string into a block of allocated
-memory and returns a pointer to the allocated block.
-Unlike the standard C library strdup() this function uses OPENSSL_malloc() and so
-should be used in preference to the standard library strdup() because it can
-be used for memory leak checking or replacing the malloc() function.
+BUF_strdup(), BUF_strndup(), BUF_memdup(), BUF_strlcpy(),
+BUF_strlcat() and BUF_strnlen are equivalents of the standard C
+library functions. The dup() functions use OPENSSL_malloc() underneath
+and so should be used in preference to the standard library for memory
+leak checking or replacing the malloc() function.
+
+Memory allocated from these functions should be freed up using the
+OPENSSL_free() function.
 
-The memory allocated from BUF_strdup() should be freed up using the OPENSSL_free()
-function.
+BUF_strndup makes the explicit guarantee that it will never read past
+the first B<siz> bytes of B<str>.
 
 =head1 RETURN VALUES
 
diff --git a/doc/crypto/d2i_X509_NAME.pod b/doc/crypto/d2i_X509_NAME.pod
index 343ffe1..b025de7 100644
--- a/doc/crypto/d2i_X509_NAME.pod
+++ b/doc/crypto/d2i_X509_NAME.pod
@@ -14,7 +14,7 @@ d2i_X509_NAME, i2d_X509_NAME - X509_NAME encoding functions
 =head1 DESCRIPTION
 
 These functions decode and encode an B<X509_NAME> structure which is the
-the same as the B<Name> type defined in RFC2459 (and elsewhere) and used
+same as the B<Name> type defined in RFC2459 (and elsewhere) and used
 for example in certificate subject and issuer names.
 
 Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
diff --git a/doc/crypto/engine.pod b/doc/crypto/engine.pod
index f5ab1c3..48741ee 100644
--- a/doc/crypto/engine.pod
+++ b/doc/crypto/engine.pod
@@ -192,7 +192,7 @@ to use the pointer value at all, as this kind of reference is a guarantee
 that the structure can not be deallocated until the reference is released.
 
 However, a structural reference provides no guarantee that the ENGINE is
-initiliased and able to use any of its cryptographic
+initialised and able to use any of its cryptographic
 implementations. Indeed it's quite possible that most ENGINEs will not
 initialise at all in typical environments, as ENGINEs are typically used to
 support specialised hardware. To use an ENGINE's functionality, you need a
@@ -201,8 +201,8 @@ specialised form of structural reference, because each functional reference
 implicitly contains a structural reference as well - however to avoid
 difficult-to-find programming bugs, it is recommended to treat the two
 kinds of reference independently. If you have a functional reference to an
-ENGINE, you have a guarantee that the ENGINE has been initialised ready to
-perform cryptographic operations and will remain uninitialised
+ENGINE, you have a guarantee that the ENGINE has been initialised and
+is ready to perform cryptographic operations, and will remain initialised
 until after you have released your reference.
 
 I<Structural references>
@@ -370,7 +370,7 @@ I<Using a specific ENGINE implementation>
 Here we'll assume an application has been configured by its user or admin
 to want to use the "ACME" ENGINE if it is available in the version of
 OpenSSL the application was compiled with. If it is available, it should be
-used by default for all RSA, DSA, and symmetric cipher operation, otherwise
+used by default for all RSA, DSA, and symmetric cipher operations, otherwise
 OpenSSL should use its builtin software as per usual. The following code
 illustrates how to approach this;
 
@@ -401,7 +401,7 @@ I<Automatically using builtin ENGINE implementations>
 
 Here we'll assume we want to load and register all ENGINE implementations
 bundled with OpenSSL, such that for any cryptographic algorithm required by
-OpenSSL - if there is an ENGINE that implements it and can be initialise,
+OpenSSL - if there is an ENGINE that implements it and can be initialised,
 it should be used. The following code illustrates how this can work;
 
  /* Load all bundled ENGINEs into memory and make them visible */