diff options
author | Gustaf Neumann <neumann@wu-wien.ac.at> | 2020-06-29 21:13:07 +0200 |
---|---|---|
committer | Dr. Matthias St. Pierre <matthias.st.pierre@ncp-e.com> | 2020-07-05 01:49:20 +0200 |
commit | 8c1cbc72105ffd493b48e65f8f5fd3657dedb28c (patch) | |
tree | b1437e0210f80d7de45d8d33903a2f28fe1b82da /doc/man3 | |
parent | 3a19f1a9dd16f5855a7e2a42cd3e7f136f849bd3 (diff) | |
download | openssl-8c1cbc72105ffd493b48e65f8f5fd3657dedb28c.tar.gz |
Fix typos and repeated words
CLA: trivial
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12320)
Diffstat (limited to 'doc/man3')
76 files changed, 112 insertions, 114 deletions
diff --git a/doc/man3/ASN1_INTEGER_get_int64.pod b/doc/man3/ASN1_INTEGER_get_int64.pod index 53a9143800..49f7ca3ac0 100644 --- a/doc/man3/ASN1_INTEGER_get_int64.pod +++ b/doc/man3/ASN1_INTEGER_get_int64.pod @@ -81,7 +81,7 @@ instead. In general an B<ASN1_INTEGER> or B<ASN1_ENUMERATED> type can contain an integer of almost arbitrary size and so cannot always be represented by a C -B<int64_t> type. However in many cases (for example version numbers) they +B<int64_t> type. However, in many cases (for example version numbers) they represent small integers which can be more easily manipulated if converted to an appropriate C integer type. diff --git a/doc/man3/ASN1_STRING_length.pod b/doc/man3/ASN1_STRING_length.pod index e3cf8bb2d0..909a3af1ca 100644 --- a/doc/man3/ASN1_STRING_length.pod +++ b/doc/man3/ASN1_STRING_length.pod @@ -72,7 +72,7 @@ In general it cannot be assumed that the data returned by ASN1_STRING_data() is null terminated or does not contain embedded nulls. The actual format of the data will depend on the actual string type itself: for example for an IA5String the data will be ASCII, for a BMPString two bytes per -character in big endian format, and for an UTF8String it will be in UTF8 format. +character in big endian format, and for a UTF8String it will be in UTF8 format. Similar care should be take to ensure the data is in the correct format when calling ASN1_STRING_set(). diff --git a/doc/man3/ASN1_TYPE_get.pod b/doc/man3/ASN1_TYPE_get.pod index a7a3083aa1..c34572345f 100644 --- a/doc/man3/ASN1_TYPE_get.pod +++ b/doc/man3/ASN1_TYPE_get.pod @@ -68,7 +68,7 @@ only return zero if the values are the same. If either or both of the parameters passed to ASN1_TYPE_cmp() is NULL the return value is nonzero. Technically if both parameters are NULL the two -types could be absent OPTIONAL fields and so should match, however passing +types could be absent OPTIONAL fields and so should match, however, passing NULL values could also indicate a programming error (for example an unparsable type which returns NULL) for types which do B<not> match. So applications should handle the case of two absent values separately. diff --git a/doc/man3/ASYNC_WAIT_CTX_new.pod b/doc/man3/ASYNC_WAIT_CTX_new.pod index 62eef297d8..ad6fe31a55 100644 --- a/doc/man3/ASYNC_WAIT_CTX_new.pod +++ b/doc/man3/ASYNC_WAIT_CTX_new.pod @@ -67,7 +67,7 @@ associated with that job in I<*fd>. The number of file descriptors returned will be stored in I<*numfds>. It is the caller's responsibility to ensure that sufficient memory has been allocated in I<*fd> to receive all the file descriptors. Calling ASYNC_WAIT_CTX_get_all_fds() with a NULL I<fd> value will -return no file descriptors but will still populate I<*numfds>. Therefore +return no file descriptors but will still populate I<*numfds>. Therefore, application code is typically expected to call this function twice: once to get the number of fds, and then again when sufficient memory has been allocated. If only one asynchronous engine is being used then normally this call will only @@ -195,7 +195,7 @@ ASYNC_WAIT_CTX_get_status() returns the engine status. On Windows platforms the openssl/async.h header is dependent on some of the types customarily made available by including windows.h. The application developer is likely to require control over when the latter -is included, commonly as one of the first included headers. Therefore +is included, commonly as one of the first included headers. Therefore, it is defined as an application developer's responsibility to include windows.h prior to async.h. diff --git a/doc/man3/ASYNC_start_job.pod b/doc/man3/ASYNC_start_job.pod index d4c6a19e61..24ef7fcbf2 100644 --- a/doc/man3/ASYNC_start_job.pod +++ b/doc/man3/ASYNC_start_job.pod @@ -170,7 +170,7 @@ otherwise. On Windows platforms the openssl/async.h header is dependent on some of the types customarily made available by including windows.h. The application developer is likely to require control over when the latter -is included, commonly as one of the first included headers. Therefore +is included, commonly as one of the first included headers. Therefore, it is defined as an application developer's responsibility to include windows.h prior to async.h. diff --git a/doc/man3/BF_encrypt.pod b/doc/man3/BF_encrypt.pod index adea85e1c9..b4a335076d 100644 --- a/doc/man3/BF_encrypt.pod +++ b/doc/man3/BF_encrypt.pod @@ -68,7 +68,7 @@ recipient needs to know what it was initialized with, or it won't be able to decrypt. Some programs and protocols simplify this, like SSH, where B<ivec> is simply initialized to zero. BF_cbc_encrypt() operates on data that is a multiple of 8 bytes long, while -BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt an variable +BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt a variable number of bytes (the amount does not have to be an exact multiple of 8). The purpose of the latter two is to simulate stream ciphers, and therefore, they need the parameter B<num>, which is a pointer to an integer where the current diff --git a/doc/man3/BIO_ADDR.pod b/doc/man3/BIO_ADDR.pod index 73c2819985..bcd83b5a14 100644 --- a/doc/man3/BIO_ADDR.pod +++ b/doc/man3/BIO_ADDR.pod @@ -42,7 +42,7 @@ BIO_ADDR_free() frees a B<BIO_ADDR> created with BIO_ADDR_new(). BIO_ADDR_clear() clears any data held within the provided B<BIO_ADDR> and sets it back to an uninitialised state. -BIO_ADDR_rawmake() takes a protocol B<family>, an byte array of +BIO_ADDR_rawmake() takes a protocol B<family>, a byte array of size B<wherelen> with an address in network byte order pointed at by B<where> and a port number in network byte order in B<port> (except for the B<AF_UNIX> protocol family, where B<port> is meaningless and diff --git a/doc/man3/BIO_ADDRINFO.pod b/doc/man3/BIO_ADDRINFO.pod index 404dd77e08..e1fe5a8e0d 100644 --- a/doc/man3/BIO_ADDRINFO.pod +++ b/doc/man3/BIO_ADDRINFO.pod @@ -94,7 +94,7 @@ information they should return isn't available. The BIO_lookup_ex() implementation uses the platform provided getaddrinfo() function. On Linux it is known that specifying 0 for the protocol will not -return any SCTP based addresses when calling getaddrinfo(). Therefore if an SCTP +return any SCTP based addresses when calling getaddrinfo(). Therefore, if an SCTP address is required then the B<protocol> parameter to BIO_lookup_ex() should be explicitly set to IPPROTO_SCTP. The same may be true on other platforms. diff --git a/doc/man3/BIO_ctrl.pod b/doc/man3/BIO_ctrl.pod index c8e3386375..5cff74f10e 100644 --- a/doc/man3/BIO_ctrl.pod +++ b/doc/man3/BIO_ctrl.pod @@ -123,7 +123,7 @@ Filter BIOs if they do not internally handle a particular BIO_ctrl() operation usually pass the operation to the next BIO in the chain. This often means there is no need to locate the required BIO for a particular operation, it can be called on a chain and it will -be automatically passed to the relevant BIO. However this can cause +be automatically passed to the relevant BIO. However, this can cause unexpected results: for example no current filter BIOs implement BIO_seek(), but this may still succeed if the chain ends in a FILE or file descriptor BIO. diff --git a/doc/man3/BIO_s_bio.pod b/doc/man3/BIO_s_bio.pod index 0f4ea77d6d..a5a66c5e8f 100644 --- a/doc/man3/BIO_s_bio.pod +++ b/doc/man3/BIO_s_bio.pod @@ -144,7 +144,7 @@ without having to go through the SSL-interface. ... BIO_new_bio_pair(&internal_bio, 0, &network_bio, 0); SSL_set_bio(ssl, internal_bio, internal_bio); - SSL_operations(); /* e.g SSL_read and SSL_write */ + SSL_operations(); /* e.g. SSL_read and SSL_write */ ... application | TLS-engine diff --git a/doc/man3/BIO_set_callback.pod b/doc/man3/BIO_set_callback.pod index eb329f527b..975fef78d2 100644 --- a/doc/man3/BIO_set_callback.pod +++ b/doc/man3/BIO_set_callback.pod @@ -31,7 +31,7 @@ BIO_callback_fn_ex, BIO_callback_fn =head1 DESCRIPTION BIO_set_callback_ex() and BIO_get_callback_ex() set and retrieve the BIO -callback. The callback is called during most high level BIO operations. It can +callback. The callback is called during most high-level BIO operations. It can be used for debugging purposes to trace operations on a BIO or to modify its operation. diff --git a/doc/man3/CMS_verify.pod b/doc/man3/CMS_verify.pod index a3dfb420b0..d56540290f 100644 --- a/doc/man3/CMS_verify.pod +++ b/doc/man3/CMS_verify.pod @@ -98,7 +98,7 @@ useful if one merely wishes to write the content to B<out> and its validity is not considered important. Chain verification should arguably be performed using the signing time rather -than the current time. However since the signing time is supplied by the +than the current time. However, since the signing time is supplied by the signer it cannot be trusted without additional evidence (such as a trusted timestamp). diff --git a/doc/man3/CRYPTO_THREAD_run_once.pod b/doc/man3/CRYPTO_THREAD_run_once.pod index ab7ff878be..dd0d21a9de 100644 --- a/doc/man3/CRYPTO_THREAD_run_once.pod +++ b/doc/man3/CRYPTO_THREAD_run_once.pod @@ -93,7 +93,7 @@ On Windows platforms the CRYPTO_THREAD_* types and functions in the openssl/crypto.h header are dependent on some of the types customarily made available by including windows.h. The application developer is likely to require control over when the latter is included, commonly as -one of the first included headers. Therefore it is defined as an +one of the first included headers. Therefore, it is defined as an application developer's responsibility to include windows.h prior to crypto.h where use of CRYPTO_THREAD_* types and functions is required. diff --git a/doc/man3/DH_set_method.pod b/doc/man3/DH_set_method.pod index ef8dbbcb4c..4782a766d4 100644 --- a/doc/man3/DH_set_method.pod +++ b/doc/man3/DH_set_method.pod @@ -52,7 +52,7 @@ DH_set_method() selects B<meth> to perform all operations using the key B<dh>. This will replace the DH_METHOD used by the DH key and if the previous method was supplied by an ENGINE, the handle to that ENGINE will be released during the change. It is possible to have DH keys that only work with certain DH_METHOD -implementations (eg. from an ENGINE module that supports embedded +implementations (e.g. from an ENGINE module that supports embedded hardware-protected keys), and in such cases attempting to change the DH_METHOD for the key can have unexpected results. diff --git a/doc/man3/DSA_set_method.pod b/doc/man3/DSA_set_method.pod index 0895e7ad0b..2a3f111b31 100644 --- a/doc/man3/DSA_set_method.pod +++ b/doc/man3/DSA_set_method.pod @@ -46,7 +46,7 @@ DSA_set_method() selects B<meth> to perform all operations using the key B<rsa>. This will replace the DSA_METHOD used by the DSA key and if the previous method was supplied by an ENGINE, the handle to that ENGINE will be released during the change. It is possible to have DSA keys that only -work with certain DSA_METHOD implementations (eg. from an ENGINE module +work with certain DSA_METHOD implementations (e.g. from an ENGINE module that supports embedded hardware-protected keys), and in such cases attempting to change the DSA_METHOD for the key can have unexpected results. See L<DSA_meth_new(3)> for information on constructing custom DSA_METHOD diff --git a/doc/man3/DTLSv1_listen.pod b/doc/man3/DTLSv1_listen.pod index ebbb9b8bc6..cb4c73d41a 100644 --- a/doc/man3/DTLSv1_listen.pod +++ b/doc/man3/DTLSv1_listen.pod @@ -35,7 +35,7 @@ message then the amplification attack has succeeded. If DTLS is used over UDP (or any datagram based protocol that does not validate the source IP) then it is susceptible to this type of attack. TLSv1.3 is designed to operate over a stream-based transport protocol (such as TCP). -If TCP is being used then there is no need to use SSL_stateless(). However some +If TCP is being used then there is no need to use SSL_stateless(). However, some stream-based transport protocols (e.g. QUIC) may not validate the source address. In this case a TLSv1.3 application would be susceptible to this attack. diff --git a/doc/man3/ECDSA_SIG_new.pod b/doc/man3/ECDSA_SIG_new.pod index f9f62543d8..6b31cbaf0a 100644 --- a/doc/man3/ECDSA_SIG_new.pod +++ b/doc/man3/ECDSA_SIG_new.pod @@ -5,7 +5,7 @@ ECDSA_SIG_get0, ECDSA_SIG_get0_r, ECDSA_SIG_get0_s, ECDSA_SIG_set0, ECDSA_SIG_new, ECDSA_SIG_free, ECDSA_size, ECDSA_sign, ECDSA_do_sign, ECDSA_verify, ECDSA_do_verify, ECDSA_sign_setup, ECDSA_sign_ex, -ECDSA_do_sign_ex - low level elliptic curve digital signature algorithm (ECDSA) +ECDSA_do_sign_ex - low-level elliptic curve digital signature algorithm (ECDSA) functions =head1 SYNOPSIS diff --git a/doc/man3/EC_GROUP_new.pod b/doc/man3/EC_GROUP_new.pod index 76fed3b246..2866b32c33 100644 --- a/doc/man3/EC_GROUP_new.pod +++ b/doc/man3/EC_GROUP_new.pod @@ -99,7 +99,7 @@ I<params>. EC_GROUP_set_curve() sets the curve parameters I<p>, I<a> and I<b>. For a curve over Fp I<p> is the prime for the field. For a curve over F2^m I<p> represents the irreducible polynomial - each bit represents a term in the polynomial. -Therefore there will either be three or five bits set dependent on whether the +Therefore, there will either be three or five bits set dependent on whether the polynomial is a trinomial or a pentanomial. In either case, I<a> and I<b> represents the coefficients a and b from the relevant equation introduced above. diff --git a/doc/man3/EC_POINT_new.pod b/doc/man3/EC_POINT_new.pod index 84b11ee0c0..83b61feb7f 100644 --- a/doc/man3/EC_POINT_new.pod +++ b/doc/man3/EC_POINT_new.pod @@ -156,7 +156,7 @@ above maps in such rare circumstances. Points can also be described in terms of their compressed co-ordinates. For a point (x, y), for any given value for x such that the point is on the curve -there will only ever be two possible values for y. Therefore a point can be set +there will only ever be two possible values for y. Therefore, a point can be set using the EC_POINT_set_compressed_coordinates() function where B<x> is the x co-ordinate and B<y_bit> is a value 0 or 1 to identify which of the two possible values for y should be used. diff --git a/doc/man3/ENGINE_add.pod b/doc/man3/ENGINE_add.pod index 307540d3e1..1d07f5df83 100644 --- a/doc/man3/ENGINE_add.pod +++ b/doc/man3/ENGINE_add.pod @@ -181,7 +181,7 @@ implementation includes the following abstractions; =head2 Reference counting and handles Due to the modular nature of the ENGINE API, pointers to ENGINEs need to be -treated as handles - ie. not only as pointers, but also as references to +treated as handles - i.e. not only as pointers, but also as references to the underlying ENGINE object. Ie. one should obtain a new reference when making copies of an ENGINE pointer if the copies will be used (and released) independently. @@ -252,7 +252,7 @@ operational ENGINE for a given cryptographic purpose. To obtain a functional reference from an existing structural reference, call the ENGINE_init() function. This returns zero if the ENGINE was not -already operational and couldn't be successfully initialised (eg. lack of +already operational and couldn't be successfully initialised (e.g. lack of system drivers, no special hardware attached, etc), otherwise it will return nonzero to indicate that the ENGINE is now operational and will have allocated a new B<functional> reference to the ENGINE. All functional @@ -260,7 +260,7 @@ references are released by calling ENGINE_finish() (which removes the implicit structural reference as well). The second way to get a functional reference is by asking OpenSSL for a -default implementation for a given task, eg. by ENGINE_get_default_RSA(), +default implementation for a given task, e.g. by ENGINE_get_default_RSA(), ENGINE_get_default_cipher_engine(), etc. These are discussed in the next section, though they are not usually required by application programmers as they are used automatically when creating and using the relevant @@ -278,7 +278,7 @@ In the case of other abstractions like RSA, DSA, etc, there is only one "algorithm" so all implementations implicitly register using the same 'nid' index. -When a default ENGINE is requested for a given abstraction/algorithm/mode, (eg. +When a default ENGINE is requested for a given abstraction/algorithm/mode, (e.g. when calling RSA_new_method(NULL)), a "get_default" call will be made to the ENGINE subsystem to process the corresponding state table and return a functional reference to an initialised ENGINE whose implementation should be @@ -328,7 +328,7 @@ is something for the application to control. Some applications will want to allow the user to specify exactly which ENGINE they want used if any is to be used at all. Others may prefer to load all support and have OpenSSL automatically use at run-time any ENGINE that is able to -successfully initialise - ie. to assume that this corresponds to +successfully initialise - i.e. to assume that this corresponds to acceleration hardware attached to the machine or some such thing. There are probably numerous other ways in which applications may prefer to handle things, so we will simply illustrate the consequences as they apply to a @@ -417,7 +417,7 @@ so that it can be initialised for use. This could include the path to any driver or config files it needs to load, required network addresses, smart-card identifiers, passwords to initialise protected devices, logging information, etc etc. This class of commands typically needs to be -passed to an ENGINE B<before> attempting to initialise it, ie. before +passed to an ENGINE B<before> attempting to initialise it, i.e. before calling ENGINE_init(). The other class of commands consist of settings or operations that tweak certain behaviour or cause certain operations to take place, and these commands may work either before or after ENGINE_init(), or @@ -490,7 +490,7 @@ It is possible to discover at run-time the names, numerical-ids, descriptions and input parameters of the control commands supported by an ENGINE using a structural reference. Note that some control commands are defined by OpenSSL itself and it will intercept and handle these control commands on behalf of the -ENGINE, ie. the ENGINE's ctrl() handler is not used for the control command. +ENGINE, i.e. the ENGINE's ctrl() handler is not used for the control command. openssl/engine.h defines an index, ENGINE_CMD_BASE, that all control commands implemented by ENGINEs should be numbered from. Any command value lower than this symbol is considered a "generic" command is handled directly by the @@ -556,7 +556,7 @@ by applications, administrations, users, etc. These can support arbitrary operations via ENGINE_ctrl(), including passing to and/or from the control commands data of any arbitrary type. These commands are supported in the discovery mechanisms simply to allow applications to determine if an ENGINE -supports certain specific commands it might want to use (eg. application "foo" +supports certain specific commands it might want to use (e.g. application "foo" might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" - and ENGINE could therefore decide whether or not to support this "foo"-specific extension). diff --git a/doc/man3/EVP_DigestInit.pod b/doc/man3/EVP_DigestInit.pod index 370b685bf8..3308ebe500 100644 --- a/doc/man3/EVP_DigestInit.pod +++ b/doc/man3/EVP_DigestInit.pod @@ -101,7 +101,7 @@ EVP_MD_do_all_provided =head1 DESCRIPTION -The EVP digest routines are a high level interface to message digests, +The EVP digest routines are a high-level interface to message digests, and should be used instead of the digest-specific functions. The B<EVP_MD> type is a structure for digest method implementation. @@ -536,7 +536,7 @@ This function has no return value. =head1 NOTES The B<EVP> interface to message digests should almost always be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the digest used and much more flexible. New applications should use the SHA-2 (such as L<EVP_sha256(3)>) or the SHA-3 diff --git a/doc/man3/EVP_DigestSignInit.pod b/doc/man3/EVP_DigestSignInit.pod index 68391dd1ff..69dec1c74d 100644 --- a/doc/man3/EVP_DigestSignInit.pod +++ b/doc/man3/EVP_DigestSignInit.pod @@ -23,7 +23,7 @@ EVP_DigestSignFinal, EVP_DigestSign - EVP signing functions =head1 DESCRIPTION -The EVP signature routines are a high level interface to digital signatures. +The EVP signature routines are a high-level interface to digital signatures. Input data is digested first before the signing takes place. EVP_DigestSignInit_ex() sets up signing context I<ctx> to use a digest with the @@ -37,7 +37,7 @@ the properties to be used during the fetch. The I<pkey> algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, to be used for the actual signing. See L<provider(7)/Implicit fetch> for -more information about implict fetches. +more information about implicit fetches. The OpenSSL default and legacy providers support fetching digests and can fetch those digests from any available provider. The OpenSSL fips provider also @@ -138,7 +138,7 @@ The error codes can be obtained from L<ERR_get_error(3)>. =head1 NOTES The B<EVP> interface to digital signatures should almost always be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the algorithm used and much more flexible. EVP_DigestSign() is a one shot operation which signs a single block of data diff --git a/doc/man3/EVP_DigestVerifyInit.pod b/doc/man3/EVP_DigestVerifyInit.pod index 617178bd19..9ea0014a5a 100644 --- a/doc/man3/EVP_DigestVerifyInit.pod +++ b/doc/man3/EVP_DigestVerifyInit.pod @@ -22,7 +22,7 @@ EVP_DigestVerifyFinal, EVP_DigestVerify - EVP signature verification functions =head1 DESCRIPTION -The EVP signature routines are a high level interface to digital signatures. +The EVP signature routines are a high-level interface to digital signatures. Input data is digested first before the signature verification takes place. EVP_DigestVerifyInit_ex() sets up verification context B<ctx> to use a digest @@ -36,7 +36,7 @@ for the properties to be used during the fetch. The I<pkey> algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, to be used for the actual signing. See L<provider(7)/Implicit fetch> for -more information about implict fetches. +more information about implicit fetches. The OpenSSL default and legacy providers support fetching digests and can fetch those digests from any available provider. The OpenSSL fips provider also @@ -130,7 +130,7 @@ The error codes can be obtained from L<ERR_get_error(3)>. =head1 NOTES The B<EVP> interface to digital signatures should almost always be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the algorithm used and much more flexible. EVP_DigestVerify() is a one shot operation which verifies a single block of diff --git a/doc/man3/EVP_EncodeInit.pod b/doc/man3/EVP_EncodeInit.pod index 0a8cbaab71..b0d00fa4b5 100644 --- a/doc/man3/EVP_EncodeInit.pod +++ b/doc/man3/EVP_EncodeInit.pod @@ -29,7 +29,7 @@ EVP_DecodeBlock - EVP base 64 encode/decode routines =head1 DESCRIPTION -The EVP encode routines provide a high level interface to base 64 encoding and +The EVP encode routines provide a high-level interface to base 64 encoding and decoding. Base 64 encoding converts binary data into a printable form that uses the characters A-Z, a-z, 0-9, "+" and "/" to represent the data. For every 3 bytes of binary data provided 4 bytes of base 64 encoded data will be produced diff --git a/doc/man3/EVP_EncryptInit.pod b/doc/man3/EVP_EncryptInit.pod index 88d0e7dabc..36efb4090d 100644 --- a/doc/man3/EVP_EncryptInit.pod +++ b/doc/man3/EVP_EncryptInit.pod @@ -165,7 +165,7 @@ EVP_CIPHER_do_all_provided =head1 DESCRIPTION -The EVP cipher routines are a high level interface to certain +The EVP cipher routines are a high-level interface to certain symmetric ciphers. The B<EVP_CIPHER> type is a structure for cipher method implementation. @@ -558,7 +558,7 @@ Sets the CCM B<L> value. If not set a default is used (8 for AES). =item EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_IVLEN, ivlen, NULL) -Sets the CCM nonce (IV) length. This call can only be made before specifying an +Sets the CCM nonce (IV) length. This call can only be made before specifying a nonce value. The nonce length is given by B<15 - L> so it is 7 by default for AES. @@ -642,10 +642,10 @@ This call is only valid when decrypting data. =head1 NOTES Where possible the B<EVP> interface to symmetric ciphers should be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the cipher used and much more flexible. Additionally, the B<EVP> interface will ensure the use of platform specific cryptographic -acceleration such as AES-NI (the low level interfaces do not provide the +acceleration such as AES-NI (the low-level interfaces do not provide the guarantee). PKCS padding works by adding B<n> padding bytes of value B<n> to make the total diff --git a/doc/man3/EVP_KDF.pod b/doc/man3/EVP_KDF.pod index 7d6228a73d..5bf7994de8 100644 --- a/doc/man3/EVP_KDF.pod +++ b/doc/man3/EVP_KDF.pod @@ -48,7 +48,7 @@ EVP_KDF_gettable_params - EVP KDF routines =head1 DESCRIPTION -The EVP KDF routines are a high level interface to Key Derivation Function +The EVP KDF routines are a high-level interface to Key Derivation Function algorithms and should be used instead of algorithm-specific functions. After creating a B<EVP_KDF_CTX> for the required algorithm using diff --git a/doc/man3/EVP_OpenInit.pod b/doc/man3/EVP_OpenInit.pod index b9a7aee738..b84f767245 100644 --- a/doc/man3/EVP_OpenInit.pod +++ b/doc/man3/EVP_OpenInit.pod @@ -16,7 +16,7 @@ EVP_OpenInit, EVP_OpenUpdate, EVP_OpenFinal - EVP envelope decryption =head1 DESCRIPTION -The EVP envelope routines are a high level interface to envelope +The EVP envelope routines are a high-level interface to envelope decryption. They decrypt a public key encrypted symmetric key and then decrypt data using it. diff --git a/doc/man3/EVP_PKEY_CTX_new.pod b/doc/man3/EVP_PKEY_CTX_new.pod index c3fc4c55ca..2634ee4a20 100644 --- a/doc/man3/EVP_PKEY_CTX_new.pod +++ b/doc/man3/EVP_PKEY_CTX_new.pod @@ -57,7 +57,7 @@ If I<ctx> is NULL, nothing is done. =head2 On B<EVP_PKEY_CTX> The B<EVP_PKEY_CTX> structure is an opaque public key algorithm context used -by the OpenSSL high level public key API. Contexts B<MUST NOT> be shared between +by the OpenSSL high-level public key API. Contexts B<MUST NOT> be shared between threads: that is it is not permissible to use the same context simultaneously in two threads. diff --git a/doc/man3/EVP_PKEY_derive.pod b/doc/man3/EVP_PKEY_derive.pod index 1bce4f3844..5bfb316382 100644 --- a/doc/man3/EVP_PKEY_derive.pod +++ b/doc/man3/EVP_PKEY_derive.pod @@ -19,7 +19,7 @@ EVP_PKEY_derive_init() initializes a public key algorithm context I<ctx> for shared secret derivation using the algorithm given when the context was created using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to fetch a B<EVP_KEYEXCH> method implicitly, see L<provider(7)/Implicit fetch> for -more information about implict fetches. +more information about implicit fetches. EVP_PKEY_derive_set_peer() sets the peer key: this will normally be a public key. diff --git a/doc/man3/EVP_PKEY_fromdata.pod b/doc/man3/EVP_PKEY_fromdata.pod index 526109386e..e3003674e3 100644 --- a/doc/man3/EVP_PKEY_fromdata.pod +++ b/doc/man3/EVP_PKEY_fromdata.pod @@ -22,7 +22,7 @@ The functions described here are used to create new keys from user provided key data, such as I<n>, I<e> and I<d> for a minimal RSA keypair. -These functions use an B<EVP_PKEY_CTX> context, which should primarly +These functions use an B<EVP_PKEY_CTX> context, which should primarily be created with L<EVP_PKEY_CTX_new_from_name(3)> or L<EVP_PKEY_CTX_new_id(3)>. diff --git a/doc/man3/EVP_PKEY_sign.pod b/doc/man3/EVP_PKEY_sign.pod index a11c1c6813..bd65bd9237 100644 --- a/doc/man3/EVP_PKEY_sign.pod +++ b/doc/man3/EVP_PKEY_sign.pod @@ -20,7 +20,7 @@ EVP_PKEY_sign_init() initializes a public key algorithm context I<ctx> for signing using the algorithm given when the context was created using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch> -for more information about implict fetches. +for more information about implicit fetches. The EVP_PKEY_sign() function performs a public key signing operation using I<ctx>. The data to be signed is specified using the I<tbs> and diff --git a/doc/man3/EVP_PKEY_verify.pod b/doc/man3/EVP_PKEY_verify.pod index b44da85c4c..c41525246a 100644 --- a/doc/man3/EVP_PKEY_verify.pod +++ b/doc/man3/EVP_PKEY_verify.pod @@ -20,7 +20,7 @@ EVP_PKEY_verify_init() initializes a public key algorithm context I<ctx> for signing using the algorithm given when the context was created using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch> -for more information about implict fetches. +for more information about implicit fetches. The EVP_PKEY_verify() function performs a public key verification operation using I<ctx>. The signature is specified using the I<sig> and diff --git a/doc/man3/EVP_PKEY_verify_recover.pod b/doc/man3/EVP_PKEY_verify_recover.pod index 8be999333b..bde2d3a8c1 100644 --- a/doc/man3/EVP_PKEY_verify_recover.pod +++ b/doc/man3/EVP_PKEY_verify_recover.pod @@ -20,7 +20,7 @@ EVP_PKEY_verify_recover_init() initializes a public key algorithm context I<ctx> for signing using the algorithm given when the context was created using L<EVP_PKEY_CTX_new(3)> or variants thereof. The algorithm is used to fetch a B<EVP_SIGNATURE> method implicitly, see L<provider(7)/Implicit fetch> -for more information about implict fetches. +for more information about implicit fetches. The EVP_PKEY_verify_recover() function recovers signed data using I<ctx>. The signature is specified using the I<sig> and diff --git a/doc/man3/EVP_RAND.pod b/doc/man3/EVP_RAND.pod index c79f5e6548..5cf62fa359 100644 --- a/doc/man3/EVP_RAND.pod +++ b/doc/man3/EVP_RAND.pod @@ -71,7 +71,7 @@ EVP_RAND_STATE_ERROR - EVP RAND routines =head1 DESCRIPTION -The EVP RAND routines are a high level interface to random number generators +The EVP RAND routines are a high-level interface to random number generators both deterministic and not. If you just want to generate random bytes then you don't need to use these functions: just call RAND_bytes() or RAND_priv_bytes(). @@ -204,7 +204,7 @@ States defined by the OpenSSL DRBGs are: =item * -EVP_RAND_STATE_UNINITIALISED: this DRBG is currently uninitalised. +EVP_RAND_STATE_UNINITIALISED: this DRBG is currently uninitialised. The instantiate call will change this to the ready state. =item * @@ -343,7 +343,7 @@ EVP_RAND_CTX_free() does not return a value. EVP_RAND_nonce() returns the length of the nonce. -EVP_RAND_strength() returns the strenght of the random number generator in bits. +EVP_RAND_strength() returns the strength of the random number generator in bits. EVP_RAND_gettable_params(), EVP_RAND_gettable_ctx_params() and EVP_RAND_settable_ctx_params() return an array of OSSL_PARAMs. diff --git a/doc/man3/EVP_SealInit.pod b/doc/man3/EVP_SealInit.pod index 73d9bb7531..35f2d876ae 100644 --- a/doc/man3/EVP_SealInit.pod +++ b/doc/man3/EVP_SealInit.pod @@ -17,7 +17,7 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption =head1 DESCRIPTION -The EVP envelope routines are a high level interface to envelope +The EVP envelope routines are a high-level interface to envelope encryption. They generate a random key and IV (if required) then "envelope" it by using public key encryption. Data can then be encrypted using this key. diff --git a/doc/man3/EVP_SignInit.pod b/doc/man3/EVP_SignInit.pod index 4bdd4fbe50..13bba5b507 100644 --- a/doc/man3/EVP_SignInit.pod +++ b/doc/man3/EVP_SignInit.pod @@ -17,7 +17,7 @@ EVP_SignInit, EVP_SignInit_ex, EVP_SignUpdate, EVP_SignFinal =head1 DESCRIPTION -The EVP signature routines are a high level interface to digital +The EVP signature routines are a high-level interface to digital signatures. EVP_SignInit_ex() sets up signing context I<ctx> to use digest @@ -48,7 +48,7 @@ The error codes can be obtained by L<ERR_get_error(3)>. =head1 NOTES The B<EVP> interface to digital signatures should almost always be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the algorithm used and much more flexible. When signing with DSA private keys the random number generator must be seeded. diff --git a/doc/man3/EVP_VerifyInit.pod b/doc/man3/EVP_VerifyInit.pod index 50afdcf8ce..deb9b387de 100644 --- a/doc/man3/EVP_VerifyInit.pod +++ b/doc/man3/EVP_VerifyInit.pod @@ -19,7 +19,7 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal =head1 DESCRIPTION -The EVP signature verification routines are a high level interface to digital +The EVP signature verification routines are a high-level interface to digital signatures. EVP_VerifyInit_ex() sets up verification context B<ctx> to use digest @@ -49,7 +49,7 @@ The error codes can be obtained by L<ERR_get_error(3)>. =head1 NOTES The B<EVP> interface to digital signatures should almost always be used in -preference to the low level interfaces. This is because the code then becomes +preference to the low-level interfaces. This is because the code then becomes transparent to the algorithm used and much more flexible. The call to EVP_VerifyFinal() internally finalizes a copy of the digest context. diff --git a/doc/man3/EVP_set_default_properties.pod b/doc/man3/EVP_set_default_properties.pod index 9135742bb2..e22f5c3e99 100644 --- a/doc/man3/EVP_set_default_properties.pod +++ b/doc/man3/EVP_set_default_properties.pod @@ -41,7 +41,7 @@ property for the given I<libctx>. =head1 RETURN VALUES EVP_set_default_properties() and EVP_default_properties_enable_fips() return 1 -on success, or 0 on failure. An error is placed on the the error stack if a +on success, or 0 on failure. An error is placed on the error stack if a failure occurs. EVP_default_properties_is_fips_enabled() returns 1 if the 'fips=yes' default diff --git a/doc/man3/OPENSSL_LH_COMPFUNC.pod b/doc/man3/OPENSSL_LH_COMPFUNC.pod index 412a4f8800..c1eb68d081 100644 --- a/doc/man3/OPENSSL_LH_COMPFUNC.pod +++ b/doc/man3/OPENSSL_LH_COMPFUNC.pod @@ -203,7 +203,7 @@ all such parameters as constant. As an example, a hash table may be maintained by code that, for reasons of encapsulation, has only "const" access to the data being -indexed in the hash table (ie. it is returned as "const" from +indexed in the hash table (i.e. it is returned as "const" from elsewhere in their code) - in this case the LHASH prototypes are appropriate as-is. Conversely, if the caller is responsible for the life-time of the data in question, then they may well wish to make diff --git a/doc/man3/OPENSSL_config.pod b/doc/man3/OPENSSL_config.pod index b75c137087..bc5510fac9 100644 --- a/doc/man3/OPENSSL_config.pod +++ b/doc/man3/OPENSSL_config.pod @@ -43,7 +43,7 @@ initialization (that is before starting any threads). There are several reasons why calling the OpenSSL configuration routines is advisable. For example, to load dynamic ENGINEs from shared libraries (DSOs). -However very few applications currently support the control interface and so +However, very few applications currently support the control interface and so very few can load and use dynamic ENGINEs. Equally in future more sophisticated ENGINEs will require certain control operations to customize them. If an application calls OPENSSL_config() it doesn't need to know or care about diff --git a/doc/man3/OPENSSL_ia32cap.pod b/doc/man3/OPENSSL_ia32cap.pod index d7c40d0b41..f3192454e3 100644 --- a/doc/man3/OPENSSL_ia32cap.pod +++ b/doc/man3/OPENSSL_ia32cap.pod @@ -102,7 +102,7 @@ and RORX; =item bit #64+19 denoting availability of ADCX and ADOX instructions; =item bit #64+21 denoting availability of VPMADD52[LH]UQ instructions, -a.k.a. AVX512IFMA extension; +aka AVX512IFMA extension; =item bit #64+29 denoting availability of SHA extension; diff --git a/doc/man3/OPENSSL_s390xcap.pod b/doc/man3/OPENSSL_s390xcap.pod index 6d5326191c..3eb5d1ad8a 100644 --- a/doc/man3/OPENSSL_s390xcap.pod +++ b/doc/man3/OPENSSL_s390xcap.pod @@ -179,7 +179,7 @@ Disables the vector facility: OPENSSL_s390xcap="stfle:~0:~0:~0x4000000000000000" -Disables the KM-XTS-AES and and the KIMD-SHAKE function codes: +Disables the KM-XTS-AES and the KIMD-SHAKE function codes: OPENSSL_s390xcap="km:~0x2800:~0;kimd:~0xc000000:~0" diff --git a/doc/man3/OSSL_CMP_log_open.pod b/doc/man3/OSSL_CMP_log_open.pod index 0f67f2ae18..fdc416c0cf 100644 --- a/doc/man3/OSSL_CMP_log_open.pod +++ b/doc/man3/OSSL_CMP_log_open.pod @@ -68,7 +68,7 @@ a severity level, and a message string describing the nature of the event, terminated by '\n'. Even when an activity is successful some warnings may be useful and some degree -of auditing may be required. Therefore the logging facility supports a severity +of auditing may be required. Therefore, the logging facility supports a severity level and the callback function has a B<level> parameter indicating such a level, such that error, warning, info, debug, etc. can be treated differently. The callback is activated only when the severity level is sufficient according @@ -76,7 +76,7 @@ to the current level of verbosity, which by default is OSSL_CMP_LOG_INFO. The callback function may itself do non-trivial tasks like writing to a log file or remote stream, which in turn may fail. -Therefore the function should return 1 on success and 0 on failure. +Therefore, the function should return 1 on success and 0 on failure. OSSL_CMP_log_open() initializes the CMP-specific logging facility to output everything to STDOUT. It fails if the integrated tracing is disabled or STDIO diff --git a/doc/man3/OSSL_PARAM_int.pod b/doc/man3/OSSL_PARAM_int.pod index 7aa6b9377f..6712a07327 100644 --- a/doc/man3/OSSL_PARAM_int.pod +++ b/doc/man3/OSSL_PARAM_int.pod @@ -187,12 +187,12 @@ OSSL_PARAM_construct_octet_string() is a function that constructs an OCTET string OSSL_PARAM structure. A parameter with name B<key>, storage B<buf> and size B<bsize> is created. -OSSL_PARAM_construct_utf8_ptr() is a function that constructes a UTF string +OSSL_PARAM_construct_utf8_ptr() is a function that constructs a UTF string pointer OSSL_PARAM structure. A parameter with name B<key>, storage pointer B<*buf> and size B<bsize> is created. -OSSL_PARAM_construct_octet_ptr() is a function that constructes an OCTET string +OSSL_PARAM_construct_octet_ptr() is a function that constructs an OCTET string pointer OSSL_PARAM structure. A parameter with name B<key>, storage pointer B<*buf> and size B<bsize> is created. diff --git a/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod b/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod index fa4ba0df4d..43dddbce02 100644 --- a/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod +++ b/doc/man3/OSSL_SERIALIZER_CTX_new_by_EVP_PKEY.pod @@ -121,7 +121,7 @@ name, thus making for the naming pattern B<OSSL_SERIALIZER_CTX_new_by_I<TYPE>>() when new types are handled. B<PUBKEY>, B<PrivateKey> and B<Parameters> in the macro names match -the B<I<TYPE>> part of of B<PEM_write_bio_I<TYPE>> functions as well +the B<I<TYPE>> part of B<PEM_write_bio_I<TYPE>> functions as well as B<i2d_I<TYPE>_bio> functions. =head1 SEE ALSO diff --git a/doc/man3/PEM_read_bio_PrivateKey.pod b/doc/man3/PEM_read_bio_PrivateKey.pod index 9b03d1a874..65ba8a8a83 100644 --- a/doc/man3/PEM_read_bio_PrivateKey.pod +++ b/doc/man3/PEM_read_bio_PrivateKey.pod @@ -215,7 +215,7 @@ RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey structure. The B<RSA_PUBKEY> functions also process an RSA public key using -an RSA structure. However the public key is encoded using a +an RSA structure. However, the public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not RSA. @@ -402,7 +402,7 @@ The pseudo code to derive the key would look similar to: =head1 BUGS The PEM read routines in some versions of OpenSSL will not correctly reuse -an existing structure. Therefore the following: +an existing structure. Therefore, the following: PEM_read_bio_X509(bp, &x, 0, NULL); diff --git a/doc/man3/PKCS7_verify.pod b/doc/man3/PKCS7_verify.pod index 200464faeb..e43a769cb0 100644 --- a/doc/man3/PKCS7_verify.pod +++ b/doc/man3/PKCS7_verify.pod @@ -91,7 +91,7 @@ useful if one merely wishes to write the content to B<out> and its validity is not considered important. Chain verification should arguably be performed using the signing time rather -than the current time. However since the signing time is supplied by the +than the current time. However, since the signing time is supplied by the signer it cannot be trusted without additional evidence (such as a trusted timestamp). diff --git a/doc/man3/RAND_DRBG_set_callbacks.pod b/doc/man3/RAND_DRBG_set_callbacks.pod index 543b3cc911..53022c8194 100644 --- a/doc/man3/RAND_DRBG_set_callbacks.pod +++ b/doc/man3/RAND_DRBG_set_callbacks.pod @@ -64,7 +64,7 @@ callbacks using RAND_DRBG_get_callback_data(). The ownership of the context data remains with the caller, i.e., it is the caller's responsibility to keep it available as long as it is needed by the callbacks and free it after use. -For more information about the the callback data see the NOTES section. +For more information about the callback data see the NOTES section. Setting the callbacks or the callback data is allowed only if the DRBG has not been initialized yet. @@ -91,7 +91,7 @@ does not satisfy the conditions requested by [NIST SP 800-90C], then it must also indicate an error by returning a buffer length of 0. See NOTES section for more details. -The B<cleanup_entropy>() callback is called from the B<drbg> to to clear and +The B<cleanup_entropy>() callback is called from the B<drbg> to clear and free the buffer allocated previously by get_entropy(). The values B<out> and B<outlen> are the random buffer's address and length, as returned by the get_entropy() callback. diff --git a/doc/man3/RSA_private_encrypt.pod b/doc/man3/RSA_private_encrypt.pod index 9f83d50845..eaa7715bfb 100644 --- a/doc/man3/RSA_private_encrypt.pod +++ b/doc/man3/RSA_private_encrypt.pod @@ -2,7 +2,7 @@ =head1 NAME -RSA_private_encrypt, RSA_public_decrypt - low level signature operations +RSA_private_encrypt, RSA_public_decrypt - low-level signature operations =head1 SYNOPSIS @@ -24,7 +24,7 @@ Both of the functions described on this page are deprecated. Applications should instead use L<EVP_PKEY_encrypt_init(3)>, L<EVP_PKEY_encrypt(3)>, L<EVP_PKEY_decrypt_init(3)> and L<EVP_PKEY_decrypt(3)>. -These functions handle RSA signatures at a low level. +These functions handle RSA signatures at a low-level. RSA_private_encrypt() signs the B<flen> bytes at B<from> (usually a message digest with an algorithm identifier) using the private key diff --git a/doc/man3/RSA_set_method.pod b/doc/man3/RSA_set_method.pod index 88ea74921d..884765ce97 100644 --- a/doc/man3/RSA_set_method.pod +++ b/doc/man3/RSA_set_method.pod @@ -58,7 +58,7 @@ RSA_set_method() selects B<meth> to perform all operations using the key B<rsa>. This will replace the RSA_METHOD used by the RSA key and if the previous method was supplied by an ENGINE, the handle to that ENGINE will be released during the change. It is possible to have RSA keys that only -work with certain RSA_METHOD implementations (eg. from an ENGINE module +work with certain RSA_METHOD implementations (e.g. from an ENGINE module that supports embedded hardware-protected keys), and in such cases attempting to change the RSA_METHOD for the key can have unexpected results. diff --git a/doc/man3/SRP_create_verifier.pod b/doc/man3/SRP_create_verifier.pod index b235fb6a4a..18c7308533 100644 --- a/doc/man3/SRP_create_verifier.pod +++ b/doc/man3/SRP_create_verifier.pod @@ -75,7 +75,7 @@ non-NULL value on success: not be freed. SRP_check_known_gN_param() returns the text representation of the group id -(ie. the prime bit size) or NULL if the arguments are not valid SRP group parameters. +(i.e. the prime bit size) or NULL if the arguments are not valid SRP group parameters. This value should not be freed. SRP_get_default_gN() returns NULL if I<id> is not a valid group size, diff --git a/doc/man3/SSL_CONF_cmd.pod b/doc/man3/SSL_CONF_cmd.pod index b060449390..753d6778df 100644 --- a/doc/man3/SSL_CONF_cmd.pod +++ b/doc/man3/SSL_CONF_cmd.pod @@ -141,7 +141,7 @@ for the B<key_share> sent by a client in a TLSv1.3 B<ClientHello>. The B<groups> argument is a colon separated list of groups. The group can be either the B<NIST> name (e.g. B<P-256>), some other commonly used name where applicable (e.g. B<X25519>, B<ffdhe2048>) or an OpenSSL OID name -(e.g B<prime256v1>). Group names are case sensitive. The list should be +(e.g. B<prime256v1>). Group names are case sensitive. The list should be in order of preference with the most preferred group first. Currently supported groups for B<TLSv1.3> are B<P-256>, B<P-384>, B<P-521>, @@ -160,7 +160,7 @@ by servers. The B<groups> argument is a curve name or the special value B<auto> which picks an appropriate curve based on client and server preferences. The curve can be either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name -(e.g B<prime256v1>). Curve names are case sensitive. +(e.g. B<prime256v1>). Curve names are case sensitive. =item B<-cipher> I<ciphers> @@ -372,7 +372,7 @@ B<ClientHello>. The B<value> argument is a colon separated list of groups. The group can be either the B<NIST> name (e.g. B<P-256>), some other commonly used name where applicable (e.g. B<X25519>, B<ffdhe2048>) or an OpenSSL OID name -(e.g B<prime256v1>). Group names are case sensitive. The list should be in +(e.g. B<prime256v1>). Group names are case sensitive. The list should be in order of preference with the most preferred group first. Currently supported groups for B<TLSv1.3> are B<P-256>, B<P-384>, B<P-521>, diff --git a/doc/man3/SSL_CTX_set1_curves.pod b/doc/man3/SSL_CTX_set1_curves.pod index b65f1b4816..5eebb2b933 100644 --- a/doc/man3/SSL_CTX_set1_curves.pod +++ b/doc/man3/SSL_CTX_set1_curves.pod @@ -35,7 +35,7 @@ SSL_set1_curves, SSL_set1_curves_list, SSL_get1_curves, SSL_get_shared_curve For all of the functions below that set the supported groups there must be at least one group in the list. A number of these functions identify groups via a -unique integer NID value. However support for some groups may be added by +unique integer NID value. However, support for some groups may be added by external providers. In this case there will be no NID assigned for the group. When setting such groups applications should use the "list" form of these functions (i.e. SSL_CTX_set1_groups_list() and SSL_set1_groups_list). diff --git a/doc/man3/SSL_CTX_set_generate_session_id.pod b/doc/man3/SSL_CTX_set_generate_session_id.pod index d90b138f81..79b58de5ff 100644 --- a/doc/man3/SSL_CTX_set_generate_session_id.pod +++ b/doc/man3/SSL_CTX_set_generate_session_id.pod @@ -108,8 +108,8 @@ server id given, and will fill the rest with pseudo random bytes: /* * Prefix the session_id with the required prefix. NB: If our * prefix is too long, clip it - but there will be worse effects - * anyway, eg. the server could only possibly create 1 session - * ID (ie. the prefix!) so all future session negotiations will + * anyway, e.g. the server could only possibly create 1 session + * ID (i.e. the prefix!) so all future session negotiations will * fail due to conflicts. */ memcpy(id, session_id_prefix, strlen(session_id_prefix) < *id_len ? diff --git a/doc/man3/SSL_CTX_set_options.pod b/doc/man3/SSL_CTX_set_options.pod index 24bf66ad85..1bf19ecd23 100644 --- a/doc/man3/SSL_CTX_set_options.pod +++ b/doc/man3/SSL_CTX_set_options.pod @@ -167,7 +167,7 @@ the session. In this way the server can operate statelessly - no session information needs to be cached locally. The TLSv1.3 protocol only supports tickets and does not directly support session -ids. However OpenSSL allows two modes of ticket operation in TLSv1.3: stateful +ids. However, OpenSSL allows two modes of ticket operation in TLSv1.3: stateful and stateless. Stateless tickets work the same way as in TLSv1.2 and below. Stateful tickets mimic the session id behaviour available in TLSv1.2 and below. The session information is cached on the server and the session id is wrapped up diff --git a/doc/man3/SSL_CTX_set_psk_client_callback.pod b/doc/man3/SSL_CTX_set_psk_client_callback.pod index c7e51f7441..23bab17317 100644 --- a/doc/man3/SSL_CTX_set_psk_client_callback.pod +++ b/doc/man3/SSL_CTX_set_psk_client_callback.pod @@ -135,7 +135,7 @@ A connection established via a TLSv1.3 PSK will appear as if session resumption has occurred so that L<SSL_session_reused(3)> will return true. There are no known security issues with sharing the same PSK between TLSv1.2 (or -below) and TLSv1.3. However the RFC has this note of caution: +below) and TLSv1.3. However, the RFC has this note of caution: "While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can diff --git a/doc/man3/SSL_CTX_set_session_cache_mode.pod b/doc/man3/SSL_CTX_set_session_cache_mode.pod index 21a782d0f2..a4c5edbf02 100644 --- a/doc/man3/SSL_CTX_set_session_cache_mode.pod +++ b/doc/man3/SSL_CTX_set_session_cache_mode.pod @@ -96,7 +96,7 @@ session caching (callback) that is configured for the SSL_CTX. This flag will prevent sessions being stored in the internal cache (though the application can add them manually using L<SSL_CTX_add_session(3)>). Note: in any SSL/TLS servers where external caching is configured, any successful -session lookups in the external cache (ie. for session-resume requests) would +session lookups in the external cache (i.e. for session-resume requests) would normally be copied into the local cache before processing continues - this flag prevents these additions to the internal cache as well. diff --git a/doc/man3/SSL_CTX_set_session_id_context.pod b/doc/man3/SSL_CTX_set_session_id_context.pod index ccc10a7e14..6b2bd70364 100644 --- a/doc/man3/SSL_CTX_set_session_id_context.pod +++ b/doc/man3/SSL_CTX_set_session_id_context.pod @@ -26,7 +26,7 @@ B<sid_ctx_len> within which a session can be reused for the B<ssl> object. Sessions are generated within a certain context. When exporting/importing sessions with B<i2d_SSL_SESSION>/B<d2i_SSL_SESSION> it would be possible, to re-import a session generated from another context (e.g. another -application), which might lead to malfunctions. Therefore each application +application), which might lead to malfunctions. Therefore, each application must set its own session id context B<sid_ctx> which is used to distinguish the contexts and is stored in exported sessions. The B<sid_ctx> can be any kind of binary data with a given length, it is therefore possible diff --git a/doc/man3/SSL_CTX_set_session_ticket_cb.pod b/doc/man3/SSL_CTX_set_session_ticket_cb.pod index e7b82606c7..6bb12cddc3 100644 --- a/doc/man3/SSL_CTX_set_session_ticket_cb.pod +++ b/doc/man3/SSL_CTX_set_session_ticket_cb.pod @@ -107,7 +107,7 @@ The return value can be any of these values: The handshake should be aborted, either because of an error or because of some policy. Note that in TLSv1.3 a client may send more than one ticket in a single -handshake. Therefore just because one ticket is unacceptable it does not mean +handshake. Therefore, just because one ticket is unacceptable it does not mean that all of them are. For this reason this option should be used with caution. =item SSL_TICKET_RETURN_IGNORE diff --git a/doc/man3/SSL_CTX_set_split_send_fragment.pod b/doc/man3/SSL_CTX_set_split_send_fragment.pod index a8af75f508..0ab84665bf 100644 --- a/doc/man3/SSL_CTX_set_split_send_fragment.pod +++ b/doc/man3/SSL_CTX_set_split_send_fragment.pod @@ -41,7 +41,7 @@ capability is known as "pipelining" within OpenSSL. In order to benefit from the pipelining capability. You need to have an engine that provides ciphers that support this. The OpenSSL "dasync" engine provides -AES128-SHA based ciphers that have this capability. However these are for +AES128-SHA based ciphers that have this capability. However, these are for development and test purposes only. SSL_CTX_set_max_send_fragment() and SSL_set_max_send_fragment() set the diff --git a/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod b/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod index 0c271b1f11..a0a4bd6367 100644 --- a/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod +++ b/doc/man3/SSL_CTX_set_tlsext_servername_callback.pod @@ -51,7 +51,7 @@ value is initialised to SSL_AD_UNRECOGNIZED_NAME. =item SSL_TLSEXT_ERR_ALERT_WARNING If this value is returned then the servername is not accepted by the server. -However the handshake will continue and send a warning alert instead. The value +However, the handshake will continue and send a warning alert instead. The value of the alert should be stored in the location pointed to by the B<al> parameter as for SSL_TLSEXT_ERR_ALERT_FATAL above. Note that TLSv1.3 does not support warning alerts, so if TLSv1.3 has been negotiated then this return value is diff --git a/doc/man3/SSL_CTX_use_psk_identity_hint.pod b/doc/man3/SSL_CTX_use_psk_identity_hint.pod index 69f7e9d4f8..e3802b74f0 100644 --- a/doc/man3/SSL_CTX_use_psk_identity_hint.pod +++ b/doc/man3/SSL_CTX_use_psk_identity_hint.pod @@ -126,7 +126,7 @@ failure. In the event of failure the connection setup fails. =head1 NOTES There are no known security issues with sharing the same PSK between TLSv1.2 (or -below) and TLSv1.3. However the RFC has this note of caution: +below) and TLSv1.3. However, the RFC has this note of caution: "While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can diff --git a/doc/man3/SSL_get_all_async_fds.pod b/doc/man3/SSL_get_all_async_fds.pod index c0cf3f6fb7..d6ef72b0de 100644 --- a/doc/man3/SSL_get_all_async_fds.pod +++ b/doc/man3/SSL_get_all_async_fds.pod @@ -32,7 +32,7 @@ appearing as "read ready" on the file descriptor (no actual data should be read from the file descriptor). This function should only be called if the B<SSL> object is currently waiting for asynchronous work to complete (i.e. B<SSL_ERROR_WANT_ASYNC> has been received - see L<SSL_get_error(3)>). Typically -the list will only contain one file descriptor. However if multiple asynchronous +the list will only contain one file descriptor. However, if multiple asynchronous capable engines are in use then more than one is possible. The number of file descriptors returned is stored in I<*numfds> and the file descriptors themselves are in I<*fds>. The I<fds> parameter may be NULL in which case no file @@ -63,7 +63,7 @@ SSL_get_all_async_fds() and SSL_get_changed_async_fds() return 1 on success or On Windows platforms the openssl/async.h header is dependent on some of the types customarily made available by including windows.h. The application developer is likely to require control over when the latter -is included, commonly as one of the first included headers. Therefore +is included, commonly as one of the first included headers. Therefore, it is defined as an application developer's responsibility to include windows.h prior to async.h. diff --git a/doc/man3/SSL_get_error.pod b/doc/man3/SSL_get_error.pod index 07466731eb..0f2b10989e 100644 --- a/doc/man3/SSL_get_error.pod +++ b/doc/man3/SSL_get_error.pod @@ -74,7 +74,7 @@ See L<SSL_read(3)> for more information. B<SSL_ERROR_WANT_WRITE> is returned when the last operation was a write to a non-blocking B<BIO> and it was unable to sent all data to the B<BIO>. -When the B<BIO> is writeable again, the same function can be called again. +When the B<BIO> is writable again, the same function can be called again. Note that the retry may again lead to an B<SSL_ERROR_WANT_READ> or B<SSL_ERROR_WANT_WRITE> condition. @@ -84,7 +84,7 @@ protocol level. It is safe to call SSL_read() or SSL_read_ex() when more data is available even when the call that set this error was an SSL_write() or SSL_write_ex(). -However if the call was an SSL_write() or SSL_write_ex(), it should be called +However, if the call was an SSL_write() or SSL_write_ex(), it should be called again to continue sending the application data. For socket B<BIO>s (e.g. when SSL_set_fd() was used), select() or diff --git a/doc/man3/SSL_pending.pod b/doc/man3/SSL_pending.pod index adc995212a..196912b6be 100644 --- a/doc/man3/SSL_pending.pod +++ b/doc/man3/SSL_pending.pod @@ -27,7 +27,7 @@ record) may have been read containing more TLS/SSL records. This also applies to DTLS and pipelining (see L<SSL_CTX_set_split_send_fragment(3)>). These additional bytes will be buffered by OpenSSL but will remain unprocessed until they are needed. As these bytes are still in an unprocessed state SSL_pending() -will ignore them. Therefore it is possible for no more bytes to be readable from +will ignore them. Therefore, it is possible for no more bytes to be readable from the underlying BIO (because OpenSSL has already read them) and for SSL_pending() to return 0, even though readable application data bytes are available (because the data is in unprocessed buffered records). diff --git a/doc/man3/SSL_read.pod b/doc/man3/SSL_read.pod index f5c02a35ad..b934df0d6a 100644 --- a/doc/man3/SSL_read.pod +++ b/doc/man3/SSL_read.pod @@ -45,7 +45,7 @@ invocation of a read function. The read functions work based on the SSL/TLS records. The data are received in records (with a maximum record size of 16kB). Only when a record has been completely received, can it be processed (decryption and check of integrity). -Therefore data that was not retrieved at the last read call can still be +Therefore, data that was not retrieved at the last read call can still be buffered inside the SSL layer and will be retrieved on the next read call. If B<num> is higher than the number of bytes buffered then the read functions will return with the bytes buffered. If no more bytes are in the diff --git a/doc/man3/SSL_read_early_data.pod b/doc/man3/SSL_read_early_data.pod index 460a436eaa..13c3bcf6a6 100644 --- a/doc/man3/SSL_read_early_data.pod +++ b/doc/man3/SSL_read_early_data.pod @@ -221,7 +221,7 @@ max_early_data for the session and the recv_max_early_data setting for the server. If a client sends more data than this then the connection will abort. The configured value for max_early_data on a server may change over time as -required. However clients may have tickets containing the previously configured +required. However, clients may have tickets containing the previously configured max_early_data value. The recv_max_early_data should always be equal to or higher than any recently configured max_early_data value in order to avoid aborted connections. The recv_max_early_data should never be set to less than @@ -317,7 +317,7 @@ cache. Applications should be designed with this in mind in order to minimise the possibility of replay attacks. The OpenSSL replay protection does not apply to external Pre Shared Keys (PSKs) -(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore extreme caution +(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore, extreme caution should be applied when combining external PSKs with early data. Some applications may mitigate the replay risks in other ways. For those diff --git a/doc/man3/SSL_set_bio.pod b/doc/man3/SSL_set_bio.pod index 1c1ec6e7d3..9d9219c4b1 100644 --- a/doc/man3/SSL_set_bio.pod +++ b/doc/man3/SSL_set_bio.pod @@ -26,7 +26,7 @@ the same value as previously). SSL_set0_wbio() works in the same as SSL_set0_rbio() except that it connects the BIO B<wbio> for the write operations of the B<ssl> object. Note that if the rbio and wbio are the same then SSL_set0_rbio() and SSL_set0_wbio() each take -ownership of one reference. Therefore it may be necessary to increment the +ownership of one reference. Therefore, it may be necessary to increment the number of references available using L<BIO_up_ref(3)> before calling the set0 functions. @@ -78,10 +78,8 @@ and no references are consumed for the B<wbio>. If the B<rbio> and B<wbio> parameters are different and the B<wbio> is the same as the previously set value and the old B<rbio> and B<wbio> values were different -to each -other then one reference is consumed for the B<rbio> and one reference -is consumed -for the B<wbio>. +to each other, then one reference is consumed for the B<rbio> and one +reference is consumed for the B<wbio>. =back diff --git a/doc/man3/UI_create_method.pod b/doc/man3/UI_create_method.pod index 5508446d4f..8d15f1b029 100644 --- a/doc/man3/UI_create_method.pod +++ b/doc/man3/UI_create_method.pod @@ -51,7 +51,7 @@ interface method creation and destruction =head1 DESCRIPTION -A method contains a few functions that implement the low level of the +A method contains a few functions that implement the low-level of the User Interface. These functions are: diff --git a/doc/man3/X509V3_get_d2i.pod b/doc/man3/X509V3_get_d2i.pod index 2b10f7527c..981eab14b8 100644 --- a/doc/man3/X509V3_get_d2i.pod +++ b/doc/man3/X509V3_get_d2i.pod @@ -78,7 +78,7 @@ of a certificate a CRL or a CRL entry respectively. =head1 NOTES In almost all cases an extension can occur at most once and multiple -occurrences is an error. Therefore the B<idx> parameter is usually B<NULL>. +occurrences is an error. Therefore, the B<idx> parameter is usually B<NULL>. The B<flags> parameter may be one of the following values. diff --git a/doc/man3/X509_LOOKUP_meth_new.pod b/doc/man3/X509_LOOKUP_meth_new.pod index 9143607d9f..2021749935 100644 --- a/doc/man3/X509_LOOKUP_meth_new.pod +++ b/doc/man3/X509_LOOKUP_meth_new.pod @@ -151,7 +151,7 @@ Implementations must add objects they find to the B<X509_STORE> object using X509_STORE_add_cert() or X509_STORE_add_crl(). This increments its reference count. However, the X509_STORE_CTX_get_by_subject() function also increases the reference count which leads to one too -many references being held. Therefore applications should +many references being held. Therefore, applications should additionally call X509_free() or X509_CRL_free() to decrement the reference count again. diff --git a/doc/man3/X509_STORE_CTX_new.pod b/doc/man3/X509_STORE_CTX_new.pod index bc765c354b..e34be08b89 100644 --- a/doc/man3/X509_STORE_CTX_new.pod +++ b/doc/man3/X509_STORE_CTX_new.pod @@ -61,7 +61,7 @@ X509_STORE_CTX_new() is the same as X509_STORE_CTX_new_with_libctx() except that the default library context and a NULL property query string are used. X509_STORE_CTX_cleanup() internally cleans up an B<X509_STORE_CTX> structure. -The context can then be reused with an new call to X509_STORE_CTX_init(). +The context can then be reused with a new call to X509_STORE_CTX_init(). X509_STORE_CTX_free() completely frees up I<ctx>. After this call I<ctx> is no longer valid. @@ -89,7 +89,7 @@ X509_STORE_CTX_set0_verified_chain() sets the validated chain used by I<ctx> to be I<chain>. Ownership of the chain is transferred to I<ctx> and should not be free'd by the caller. -X509_STORE_CTX_get0_chain() returns a the internal pointer used by the +X509_STORE_CTX_get0_chain() returns the internal pointer used by the I<ctx> that contains the validated chain. X509_STORE_CTX_set0_crls() sets a set of CRLs to use to aid certificate @@ -142,7 +142,7 @@ should be made or reference counts increased instead. =head1 RETURN VALUES -X509_STORE_CTX_new() returns an newly allocates context or B<NULL> is an +X509_STORE_CTX_new() returns a newly allocates context or B<NULL> is an error occurred. X509_STORE_CTX_init() returns 1 for success or 0 if an error occurred. diff --git a/doc/man3/X509_STORE_CTX_set_verify_cb.pod b/doc/man3/X509_STORE_CTX_set_verify_cb.pod index 3c081e1de7..cfde5ab5ba 100644 --- a/doc/man3/X509_STORE_CTX_set_verify_cb.pod +++ b/doc/man3/X509_STORE_CTX_set_verify_cb.pod @@ -50,7 +50,7 @@ The verification callback can be used to customise the operation of certificate verification, either by overriding error conditions or logging errors for debugging purposes. -However a verification callback is B<not> essential and the default operation +However, a verification callback is B<not> essential and the default operation is often sufficient. The B<ok> parameter to the callback indicates the value the callback should diff --git a/doc/man3/X509_check_host.pod b/doc/man3/X509_check_host.pod index 7732cb80f3..459c37652d 100644 --- a/doc/man3/X509_check_host.pod +++ b/doc/man3/X509_check_host.pod @@ -37,7 +37,7 @@ Per section 6.4.2 of RFC 6125, B<name> values representing international domain names must be given in A-label form. The B<namelen> argument must be the number of characters in the name string or zero in which case the length is calculated with strlen(B<name>). When B<name> starts -with a dot (e.g ".example.com"), it will be matched by a certificate +with a dot (e.g. ".example.com"), it will be matched by a certificate valid for any sub-domain of B<name>, (see also B<X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS> below). diff --git a/doc/man3/X509_check_purpose.pod b/doc/man3/X509_check_purpose.pod index bc38138743..6af9e79815 100644 --- a/doc/man3/X509_check_purpose.pod +++ b/doc/man3/X509_check_purpose.pod @@ -35,7 +35,7 @@ For non-CA checks =over 4 -=item -1 an error condition has occured +=item -1 an error condition has occurred =item E<32>1 if the certificate was created to perform the purpose represented by I<id> @@ -47,7 +47,7 @@ For CA checks the below integers could be returned with the following meanings: =over 4 -=item -1 an error condition has occured +=item -1 an error condition has occurred =item E<32>0 not a CA or does not have the purpose represented by I<id> diff --git a/doc/man3/d2i_X509.pod b/doc/man3/d2i_X509.pod index fdf6c1d669..971339bba0 100644 --- a/doc/man3/d2i_X509.pod +++ b/doc/man3/d2i_X509.pod @@ -472,7 +472,7 @@ populated B<I<TYPE>> structure -- it B<cannot> simply be fed with an empty structure such as that returned by TYPE_new(). The encoded data is in binary form and may contain embedded zeros. -Therefore any FILE pointers or BIOs should be opened in binary mode. +Therefore, any FILE pointers or BIOs should be opened in binary mode. Functions such as strlen() will B<not> return the correct length of the encoded structure. |