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)

.github/PULL_REQUEST_TEMPLATE.md

@@ -5,7 +5,7 @@ Contributors guide: https://github.com/openssl/openssl/blob/master/CONTRIBUTING.
 
 Other than that, provide a description above this comment if there isn't one already
 
-If this fixes a github issue, make sure to have a line saying 'Fixes #XXXX' (without quotes) in the commit message.
+If this fixes a GitHub issue, make sure to have a line saying 'Fixes #XXXX' (without quotes) in the commit message.
 -->
 
 ##### Checklist

INSTALL.md

@@ -167,7 +167,7 @@ Use the following commands to build OpenSSL:
 ### Windows
 
 If you are using Visual Studio, open a Developer Command Prompt and
-and issue the following commands to build OpenSSL.
+issue the following commands to build OpenSSL.
 
     $ perl Configure
     $ nmake
@@ -192,7 +192,7 @@ paragraphs carefully before you install OpenSSL.
 For security reasons the default system location is by default not writable
 for unprivileged users.  So for the final installation step administrative
 privileges are required.  The default system location and the procedure to
-obtain administrative privileges depends on the operating sytem.
+obtain administrative privileges depends on the operating system.
 It is recommended to compile and test OpenSSL with normal user privileges
 and use administrative privileges only for the final installation step.
 
@@ -482,8 +482,8 @@ be a hex string no more than 64 characters.
 Enable and Disable Features
 ---------------------------
 
-Feature options always come in pairs, an option to enable feature `xxxx`, and
-and option to disable it:
+Feature options always come in pairs, an option to enable feature
+`xxxx`, and an option to disable it:
 
     [ enable-xxxx | no-xxxx ]
 
@@ -852,7 +852,7 @@ Don't build with support for multi-threaded applications.
 ### threads
 
 Build with support for multi-threaded applications.  Most platforms will enable
-this by default.  However if on a platform where this is not the case then this
+this by default.  However, if on a platform where this is not the case then this
 will usually require additional system-dependent options!
 
 See [Notes on multi-threading](#notes-on-multi-threading) below.
@@ -1457,7 +1457,7 @@ described here.  Examine the Makefiles themselves for the full list.
                    Only install the OpenSSL man pages (Unix only).
 
     install_html_docs
-                   Only install the OpenSSL html documentation.
+                   Only install the OpenSSL HTML documentation.
 
     list-tests
                    Prints a list of all the self test names.
@@ -1683,7 +1683,7 @@ to deliver random bytes and a "PRNG not seeded error" will occur.
 
 The seeding method can be configured using the `--with-rand-seed` option,
 which can be used to specify a comma separated list of seed methods.
-However in most cases OpenSSL will choose a suitable default method,
+However, in most cases OpenSSL will choose a suitable default method,
 so it is not necessary to explicitly provide this option.  Note also
 that not all methods are available on all platforms.
 

NEWS.md

@@ -27,7 +27,7 @@ OpenSSL 3.0
     will not be accidentially used.
   * The algorithm specific public key command line applications have
     been deprecated.  These include dhparam, gendsa and others.  The pkey
-    alternatives should be used intead: pkey, pkeyparam and genpkey.
+    alternatives should be used instead: pkey, pkeyparam and genpkey.
   * X509 certificates signed using SHA1 are no longer allowed at security
     level 1 or higher. The default security level for TLS is 1, so
     certificates signed using SHA1 are by default no longer trusted to
@@ -57,12 +57,12 @@ OpenSSL 3.0
   * Removed the heartbeat message in DTLS feature.
   * Added EVP_KDF, an EVP layer KDF API, and a generic EVP_PKEY to EVP_KDF
     bridge.
-  * All of the low level MD2, MD4, MD5, MDC2, RIPEMD160, SHA1, SHA224,
+  * All of the low-level MD2, MD4, MD5, MDC2, RIPEMD160, SHA1, SHA224,
     SHA256, SHA384, SHA512 and Whirlpool digest functions have been
     deprecated.
-  * All of the low level AES, Blowfish, Camellia, CAST, DES, IDEA, RC2,
+  * All of the low-level AES, Blowfish, Camellia, CAST, DES, IDEA, RC2,
     RC4, RC5 and SEED cipher functions have been deprecated.
-  * All of the low level DH, DSA, ECDH, ECDSA and RSA public key functions
+  * All of the low-level DH, DSA, ECDH, ECDSA and RSA public key functions
     have been deprecated.
   * SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0.
 
@@ -681,7 +681,7 @@ OpenSSL 1.0.0
   Known issues in OpenSSL 1.0.0m:
 
   * EAP-FAST and other applications using tls_session_secret_cb
-    wont resume sessions. Fixed in 1.0.0n-dev
+    won't resume sessions. Fixed in 1.0.0n-dev
   * Compilation failure of s3_pkt.c on some platforms due to missing
     `<limits.h>` include. Fixed in 1.0.0n-dev
 
@@ -1189,7 +1189,7 @@ OpenSSL 0.9.x
   * Enhanced chain verification using key identifiers.
   * New sign and verify options to 'dgst' application.
   * Support for DER and PEM encoded messages in 'smime' application.
-  * New 'rsautl' application, low level RSA utility.
+  * New 'rsautl' application, low-level RSA utility.
   * MD4 now included.
   * Bugfix for SSL rollback padding check.
   * Support for external crypto devices [1].
@@ -1241,7 +1241,7 @@ OpenSSL 0.9.x
   * BIGNUM library bug fixes
   * Faster DSA parameter generation
   * Enhanced support for Alpha Linux
-  * Experimental MacOS support
+  * Experimental macOS support
 
 ### Major changes between OpenSSL 0.9.3 and OpenSSL 0.9.4 [9 Aug 1999]
 

NOTES.ANDROID

@@ -6,8 +6,8 @@
  -------------------
 
  Beside basic tools like perl and make you'll need to download the Android
- NDK. It's available for Linux, Mac OS X and Windows, but only Linux
- version was actually tested. There is no reason to believe that Mac OS X
+ NDK. It's available for Linux, macOS and Windows, but only Linux
+ version was actually tested. There is no reason to believe that macOS
  wouldn't work. And as for Windows, it's unclear which "shell" would be
  suitable, MSYS2 might have best chances. NDK version should play lesser
  role, the goal is to support a range of most recent versions.

NOTES.VMS

@@ -18,7 +18,7 @@
  An ANSI C compiled is needed among other things.  This means that
  VAX C is not and will not be supported.
 
- We have only tested with DEC C (a.k.a HP VMS C / VSI C) and require
+ We have only tested with DEC C (aka HP VMS C / VSI C) and require
  version 7.1 or later.  Compiling with a different ANSI C compiler may
  require some work.
 

NOTES.WIN

@@ -18,7 +18,7 @@
  For this option you can use Cygwin.
 
 
- Visual C++ native builds, a.k.a. VC-*
+ Visual C++ native builds, aka VC-*
  =====================================
 
  Requirement details
@@ -100,7 +100,7 @@
  is, of course, to choose a different set of directories by using
  --prefix and --openssldir when configuring.
 
- Special notes for Universal Windows Platform builds, a.k.a. VC-*-UWP
+ Special notes for Universal Windows Platform builds, aka VC-*-UWP
  --------------------------------------------------------------------
 
  - UWP targets only support building the static and dynamic libraries.
@@ -119,7 +119,7 @@
 
    MSYS2 provides GNU tools, a Unix-like command prompt,
    and a UNIX compatibility layer for applications.
-   However in this context it is only used for building OpenSSL.
+   However, in this context it is only used for building OpenSSL.
    The resulting OpenSSL does not rely on MSYS2 to run and is fully native.
 
    Requirement details

doc/internal/man3/OPENSSL_SA.pod

@@ -69,7 +69,7 @@ elements.  After this call I<sa> is no longer valid.
 B<ossl_sa_I<TYPE>_doall>() calls the function I<leaf> for each element in I<sa>
 in ascending index order. The index position, within the sparse array,
 of each item is passed as the first argument to the leaf function and a
-pointer to the associated value is is passed as the second argument.
+pointer to the associated value is passed as the second argument.
 
 B<ossl_sa_I<TYPE>_doall_arg>() calls the function I<leaf> for each element in
 I<sa> in ascending index order. The index position, within the sparse

doc/internal/man3/s2i_ASN1_UTF8STRING.pod

@@ -18,7 +18,7 @@ s2i_ASN1_UTF8STRING
 =head1 DESCRIPTION
 
 These functions convert OpenSSL objects to and from their ASN.1/string
-representation. This function is used for B<X509v3> extentions.
+representation. This function is used for B<X509v3> extensions.
 
 =head1 NOTES
 

doc/internal/man7/DERlib.pod

@@ -7,7 +7,7 @@ DERlib - internal OpenSSL DER library
 =head1 DESCRIPTION
 
 OpenSSL contains an internal small DER reading and writing library,
-as an alternative to the publically known i2d and d2i functions.  It's
+as an alternative to the publicly known i2d and d2i functions.  It's
 solely constituted of functions that work as building blocks to create
 more similar functions to encode and decode larger structures.
 
@@ -47,7 +47,7 @@ which is defined like this in ASN.1 terms:
             r       INTEGER,
             s       INTEGER  }
 
-With the DER library, this is the correspoding code, given two OpenSSL
+With the DER library, this is the corresponding code, given two OpenSSL
 B<BIGNUM>s I<r> and I<s>:
 
     int ok = DER_w_begin_sequence(pkt, -1)

doc/internal/man7/EVP_PKEY.pod

@@ -19,12 +19,11 @@ private/public key key pairs, but has had other uses as well.
 
 =for comment "uses" could as well be "abuses"...
 
-It can contain the legacy form of keys -- i.e. pointers to the low
-level key types, such as B<RSA>, B<DSA> and B<EC> --, but also the
+It can contain the legacy form of keys -- i.e. pointers to the low-level key types, such as B<RSA>, B<DSA> and B<EC> --, but also the
 provided form of keys -- i.e. pointers to provider side key data.
 Those two forms are mutually exclusive; an B<EVP_PKEY> instance can't
 contain both a key in legacy form and in provided form.  Regardless of
-form, this key is commonly refered to as the "origin".
+form, this key is commonly referred to as the "origin".
 
 An B<EVP_PKEY> also contains a cache of provider side copies of the
 key, each adapted for the provider that is going to use that copy to

doc/internal/man7/build.info.pod

@@ -610,7 +610,7 @@ B<SCRIPTS>.
 For OpenSSL::Template documentation,
 C<perldoc -o man util/perl/OpenSSL/Template.pm>
 
-L<Text::Temlate|https://metacpan.org/pod/Text::Template>
+L<Text::Template|https://metacpan.org/pod/Text::Template>
 
 =head1 COPYRIGHT
 

doc/man1/openssl-ca.pod.in

@@ -253,7 +253,7 @@ DNs match the order of the request. This is not needed for Xenroll.
 =item B<-noemailDN>
 
 The DN of a certificate can contain the EMAIL field if present in the
-request DN, however it is good policy just having the e-mail set into
+request DN, however, it is good policy just having the e-mail set into
 the altName extension of the certificate. When this option is set the
 EMAIL field is removed from the certificate' subject and set only in
 the, eventually present, extensions. The B<email_in_dn> keyword can be

doc/man1/openssl-cmp.pod.in

@@ -1104,7 +1104,7 @@ This prints information about all received ITAV B<infoType>s to stdout.
 For CMP client invocations, in particular for certificate enrollment,
 usually many parameters need to be set, which is tedious and error-prone to do
 on the command line.
-Therefore the client offers the possibility to read
+Therefore, the client offers the possibility to read
 options from sections of the OpenSSL config file, usually called B<openssl.cnf>.
 The values found there can still be extended and even overridden by any
 subsequently loaded sections and on the command line.

doc/man1/openssl-dsa.pod.in

@@ -62,7 +62,7 @@ The input and formats; the default is B<PEM>.
 See L<openssl(1)/Format Options> for details.
 
 Private keys are a sequence of B<ASN.1 INTEGERS>: the version (zero), B<p>,
-B<q>, B<g>, and the public and and private key components.  Public keys
+B<q>, B<g>, and the public and private key components.  Public keys
 are a B<SubjectPublicKeyInfo> structure with the B<DSA> type.
 
 The B<PEM> format also accepts PKCS#8 data.

doc/man1/openssl-enc.pod.in

@@ -241,7 +241,7 @@ a strong block cipher, such as AES, in CBC mode.
 
 All the block ciphers normally use PKCS#5 padding, also known as standard
 block padding. This allows a rudimentary integrity or password check to
-be performed. However since the chance of random data passing the test
+be performed. However, since the chance of random data passing the test
 is better than 1 in 256 it isn't a very good test.
 
 If padding is disabled then the input data must be a multiple of the cipher

doc/man1/openssl-pkcs12.pod.in

@@ -244,7 +244,7 @@ This option is only interpreted by MSIE and similar MS software. Normally
 encryption purposes but arbitrary length keys for signing. The B<-keysig>
 option marks the key for signing only. Signing only keys can be used for
 S/MIME signing, authenticode (ActiveX control signing)  and SSL client
-authentication, however due to a bug only MSIE 5.0 and later support
+authentication, however, due to a bug only MSIE 5.0 and later support
 the use of signing only keys for SSL client authentication.
 
 =item B<-macalg> I<digest>

doc/man1/openssl-pkcs8.pod.in

@@ -248,7 +248,7 @@ one million iterations of the password:
 Test vectors from this PKCS#5 v2.0 implementation were posted to the
 pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
 counts, several people confirmed that they could decrypt the private
-keys produced and Therefore it can be assumed that the PKCS#5 v2.0
+keys produced and therefore, it can be assumed that the PKCS#5 v2.0
 implementation is reasonably accurate at least as far as these
 algorithms are concerned.
 

doc/man1/openssl-pkeyutl.pod.in

@@ -43,7 +43,7 @@ B<openssl> B<pkeyutl>
 
 =head1 DESCRIPTION
 
-This command can be used to perform low level public key
+This command can be used to perform low-level public key
 operations using any supported algorithm.
 
 =head1 OPTIONS

doc/man1/openssl-s_client.pod.in

@@ -192,7 +192,7 @@ When used with the B<-proxy> flag, the program will attempt to authenticate
 with the specified proxy using basic (base64) authentication.
 NB: Basic authentication is insecure; the credentials are sent to the proxy
 in easily reversible base64 encoding before any TLS/SSL session is established.
-Therefore these credentials are easily recovered by anyone able to sniff/trace
+Therefore, these credentials are easily recovered by anyone able to sniff/trace
 the network. Use with caution.
 
 =item B<-proxy_pass> I<arg>
@@ -854,14 +854,14 @@ is that a web client complains it has no certificates or gives an empty
 list to choose from. This is normally because the server is not sending
 the clients certificate authority in its "acceptable CA list" when it
 requests a certificate. By using this command, the CA list can be viewed
-and checked. However some servers only request client authentication
+and checked. However, some servers only request client authentication
 after a specific URL is requested. To obtain the list in this case it
 is necessary to use the B<-prexit> option and send an HTTP request
 for an appropriate page.
 
 If a certificate is specified on the command line using the B<-cert>
 option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
 on the command line is no guarantee that the certificate works.
 
 If there are problems verifying a server certificate then the

doc/man1/openssl-s_server.pod.in

@@ -433,9 +433,9 @@ For more information on shutting down a connection, see L<SSL_shutdown(3)>.
 =item B<-id_prefix> I<val>
 
 Generate SSL/TLS session IDs prefixed by I<val>. This is mostly useful
-for testing any SSL/TLS code (eg. proxies) that wish to deal with multiple
+for testing any SSL/TLS code (e.g. proxies) that wish to deal with multiple
 servers, when each of which might be generating a unique range of session
-IDs (eg. with a certain prefix).
+IDs (e.g. with a certain prefix).
 
 =item B<-verify_return_error>
 

doc/man1/openssl-s_time.pod.in

@@ -157,14 +157,14 @@ is that a web client complains it has no certificates or gives an empty
 list to choose from. This is normally because the server is not sending
 the clients certificate authority in its "acceptable CA list" when it
 requests a certificate. By using L<openssl-s_client(1)> the CA list can be
-viewed and checked. However some servers only request client authentication
+viewed and checked. However, some servers only request client authentication
 after a specific URL is requested. To obtain the list in this case it
 is necessary to use the B<-prexit> option of L<openssl-s_client(1)> and
 send an HTTP request for an appropriate page.
 
 If a certificate is specified on the command line using the B<-cert>
 option it will not be used unless the server specifically requests
-a client certificate. Therefore merely including a client certificate
+a client certificate. Therefore, merely including a client certificate
 on the command line is no guarantee that the certificate works.
 
 =head1 BUGS

doc/man1/openssl-sess_id.pod.in

@@ -136,7 +136,7 @@ This is the return code when an SSL client certificate is verified.
 
 Since the SSL session output contains the master key it is
 possible to read the contents of an encrypted session using this
-information. Therefore appropriate security precautions should be taken if
+information. Therefore, appropriate security precautions should be taken if
 the information is being output by a "real" application. This is however
 strongly discouraged and should only be used for debugging purposes.
 

doc/man1/openssl.pod

@@ -1125,7 +1125,7 @@ a string and leading or trailing spaces.
 =item B<esc_2254>
 
 Escape the "special" characters in a field as required by RFC 2254 in a field.
-That is, the B<NUL> character and and of C<()*>.
+That is, the B<NUL> character and of C<()*>.
 
 =item B<esc_ctrl>
 

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.
 

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().

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.

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.
 

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.
 

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

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

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.
 

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.

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

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.
 

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).
 

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.
 

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.
 

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

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.
 

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

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.

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.

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).

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

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

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

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

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

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

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.
 

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.
 

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.

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)>.
 

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

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

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

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.

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.

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.

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.

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

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

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

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;
 

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"
 

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

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.

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

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);
 

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).
 

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.

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

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.

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,

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

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).

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 ?

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

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

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.
 

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

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

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

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

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

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.
 

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

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).

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

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

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
 

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:
 

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.
 

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.
 

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.

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

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).
 

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>
 

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.
 

doc/man5/x509v3_config.pod

@@ -167,7 +167,7 @@ Examples:
 This is a string extension with one of two legal values. If it is the word
 B<hash>, then OpenSSL will follow the process in RFC 5280 to calculate the
 hash value.
-Otherwise, the value should be a hex string to output directly, however this
+Otherwise, the value should be a hex string to output directly, however, this
 is strongly discouraged.
 
 Example: