diff options
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 |