Fix typos found by codespell

Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22063)

8 files changed, 12 insertions, 12 deletions

diff --git a/doc/internal/man3/ossl_provider_new.pod b/doc/internal/man3/ossl_provider_new.pod
index e170edf343..d30e400894 100644
--- a/doc/internal/man3/ossl_provider_new.pod
+++ b/doc/internal/man3/ossl_provider_new.pod
@@ -291,7 +291,7 @@ in a bitstring that's internal to I<provider>.
 
 ossl_provider_test_operation_bit() checks if the bit operation I<bitnum>
 is set (1) or not (0) in the internal I<provider> bitstring, and sets
-I<*result> to 1 or 0 accorddingly.
+I<*result> to 1 or 0 accordingly.
 
 ossl_provider_init_as_child() stores in the library context I<ctx> references to
 the necessary upcalls for managing child providers. The I<handle> and I<in>
diff --git a/doc/man3/EVP_MAC.pod b/doc/man3/EVP_MAC.pod
index 13482ac5e1..8fd237599e 100644
--- a/doc/man3/EVP_MAC.pod
+++ b/doc/man3/EVP_MAC.pod
@@ -181,7 +181,7 @@ EVP_MAC_CTX_set_params() passes chosen parameters to the underlying
 context, given a context I<ctx>.
 The set of parameters given with I<params> determine exactly what
 parameters are passed down.
-If I<params> are NULL, the unterlying context should do nothing and return 1.
+If I<params> are NULL, the underlying context should do nothing and return 1.
 Note that a parameter that is unknown in the underlying context is
 simply ignored.
 Also, what happens when a needed parameter isn't passed down is
diff --git a/doc/man3/EVP_SIGNATURE.pod b/doc/man3/EVP_SIGNATURE.pod
index 6005220853..a4ee9c4807 100644
--- a/doc/man3/EVP_SIGNATURE.pod
+++ b/doc/man3/EVP_SIGNATURE.pod
@@ -61,7 +61,7 @@ EVP_SIGNATURE_get0_provider() returns the provider that I<signature> was
 fetched from.
 
 EVP_SIGNATURE_do_all_provided() traverses all SIGNATURE implemented by all
-activated roviders in the given library context I<libctx>, and for each of the
+activated providers in the given library context I<libctx>, and for each of the
 implementations, calls the given function I<fn> with the implementation method
 and the given I<arg> as argument.
 
diff --git a/doc/man5/x509v3_config.pod b/doc/man5/x509v3_config.pod
index 2440f23ddd..ab33b7e7af 100644
--- a/doc/man5/x509v3_config.pod
+++ b/doc/man5/x509v3_config.pod
@@ -93,7 +93,7 @@ numeric identifier, as shown here:
  email.2 = steve@example.org
 
 The syntax of raw extensions is defined by the source code that parses
-the extension but should be documened.
+the extension but should be documented.
 See L</Certificate Policies> for an example of a raw extension.
 
 If an extension type is unsupported, then the I<arbitrary> extension syntax
diff --git a/doc/man7/ossl-guide-quic-client-non-block.pod b/doc/man7/ossl-guide-quic-client-non-block.pod
index 8187bb9b77..0c2b916b80 100644
--- a/doc/man7/ossl-guide-quic-client-non-block.pod
+++ b/doc/man7/ossl-guide-quic-client-non-block.pod
@@ -43,7 +43,7 @@ L<SSL_read_ex(3)> or L<SSL_write_ex(3)> will return immediately with a non-fatal
 error if they are currently unable to read or write respectively.
 
 Since this page is building on the example developed on the
-L<ossl-guide-quic-client-block(7)> page we assume that you are familar with it
+L<ossl-guide-quic-client-block(7)> page we assume that you are familiar with it
 and we only explain how this example differs.
 
 =head2 Performing work while waiting for the socket
@@ -407,7 +407,7 @@ L<SSL_shutdown(3)>.
 
 Since our application is initiating the shutdown then we might expect to see
 L<SSL_shutdown(3)> give a return value of 0, and then we should continue to call
-it until we recieve a return value of 1 (meaning we have successfully completed
+it until we receive a return value of 1 (meaning we have successfully completed
 the shutdown). Since we are using a nonblocking B<SSL> object we might expect to
 have to retry this operation several times. If L<SSL_shutdown(3)> returns a
 negative result then we must call L<SSL_get_error(3)> to work out what to do
diff --git a/doc/man7/ossl-guide-quic-multi-stream.pod b/doc/man7/ossl-guide-quic-multi-stream.pod
index 4e4d852b03..877d2208ae 100644
--- a/doc/man7/ossl-guide-quic-multi-stream.pod
+++ b/doc/man7/ossl-guide-quic-multi-stream.pod
@@ -96,7 +96,7 @@ When using a default stream OpenSSL will prevent new streams from being
 accepted. To override this behaviour you must call
 L<SSL_set_incoming_stream_policy(3)> to set the policy to
 B<SSL_INCOMING_STREAM_POLICY_ACCEPT>. See the man page for further details. This
-is not relevant if the default stream has been disabed as described in
+is not relevant if the default stream has been disabled as described in
 L</THE DEFAULT STREAM> above.
 
 Any stream may be bi-directional or uni-directional. If it is uni-directional
diff --git a/doc/man7/ossl-guide-tls-client-block.pod b/doc/man7/ossl-guide-tls-client-block.pod
index 865a5353b3..646b58081a 100644
--- a/doc/man7/ossl-guide-tls-client-block.pod
+++ b/doc/man7/ossl-guide-tls-client-block.pod
@@ -124,7 +124,7 @@ function and passing the B<SSL_CTX> we created as an argument.
 =head2 Creating the socket and BIO
 
 TLS data is transmitted over an underlying transport layer. Normally a TCP
-socket. It is the application's resonsibility for ensuring that the socket is
+socket. It is the application's responsibility for ensuring that the socket is
 created and associated with an SSL object (via a BIO).
 
 Socket creation for use by a client is typically a 2 step process, i.e.
@@ -549,7 +549,7 @@ intermediate CAs, or the issuer is simply unrecognised).
 =head1 FURTHER READING
 
 See L<ossl-guide-tls-client-non-block(7)> to read a tutorial on how to modify
-the client devloped on this page to support a nonblocking socket.
+the client developed on this page to support a nonblocking socket.
 
 See L<ossl-guide-quic-client-block(7)> to read a tutorial on how to modify the
 client developed on this page to support QUIC instead of TLS.
diff --git a/doc/man7/ossl-guide-tls-client-non-block.pod b/doc/man7/ossl-guide-tls-client-non-block.pod
index ea5e40bd1c..1eabcc0b57 100644
--- a/doc/man7/ossl-guide-tls-client-non-block.pod
+++ b/doc/man7/ossl-guide-tls-client-non-block.pod
@@ -41,7 +41,7 @@ behaviour is propagated up to the application so that OpenSSL I/O functions such
 as L<SSL_read_ex(3)> or L<SSL_write_ex(3)> will not block.
 
 Since this page is building on the example developed on the
-L<ossl-guide-tls-client-block(7)> page we assume that you are familar with it
+L<ossl-guide-tls-client-block(7)> page we assume that you are familiar with it
 and we only explain how this example differs.
 
 =head2 Setting the socket to be nonblocking
@@ -162,7 +162,7 @@ Fatal errors that may occur are B<SSL_ERROR_SYSCALL> and B<SSL_ERROR_SSL>. These
 indicate that the underlying connection has failed. You should not attempt to
 shut it down with L<SSL_shutdown(3)>. B<SSL_ERROR_SYSCALL> indicates that
 OpenSSL attempted to make a syscall that failed. You can consult B<errno> for
-further details. B<SSL_ERROR_SSL> indicates that some OpenSSL error occured. You
+further details. B<SSL_ERROR_SSL> indicates that some OpenSSL error occurred. You
 can consult the OpenSSL error stack for further details (for example by calling
 L<ERR_print_errors(3)> to print out details of errors that have occurred).
 
@@ -313,7 +313,7 @@ finished with it.
 
 If our application was initiating the shutdown then we would expect to see
 L<SSL_shutdown(3)> give a return value of 0, and then we would continue to call
-it until we recieved a return value of 1 (meaning we have successfully completed
+it until we received a return value of 1 (meaning we have successfully completed
 the shutdown). In this particular example we don't expect SSL_shutdown() to
 return 0 because we have already received EOF from the server indicating that it
 has shutdown already. So we just keep calling it until SSL_shutdown() returns 1.