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)

apps/progs.pl

@@ -104,7 +104,7 @@ EOF
 # The format of this table is:
 #   [0] = alternative command to use instead
 #   [1] = deprecented in this version
-#   [2] = preprocessor conditional for exclusing irrespective of deprecation
+#   [2] = preprocessor conditional for excluding irrespective of deprecation
 #        rsa      => [ "pkey",      "3_0", "rsa" ],
 #        genrsa   => [ "genpkey",   "3_0", "rsa" ],
         rsautl   => [ "pkeyutl",   "3_0", "rsa" ],

crypto/bio/bio_print.c

@@ -62,7 +62,7 @@ static int _dopr(char **sbuffer, char **buffer,
 #define DP_F_NUM        (1 << 3)
 /* print leading zeroes */
 #define DP_F_ZERO       (1 << 4)
-/* print HEX in UPPPERcase */
+/* print HEX in UPPERcase */
 #define DP_F_UP         (1 << 5)
 /* treat value as unsigned */
 #define DP_F_UNSIGNED   (1 << 6)

crypto/err/err.c

@@ -831,7 +831,7 @@ void ERR_add_error_vdata(int num, va_list args)
     i = es->top;
 
     /*
-     * If err_data is allocated already, re-use the space.
+     * If err_data is allocated already, reuse the space.
      * Otherwise, allocate a small new buffer.
      */
     if ((es->err_data_flags[i] & flags) == flags) {

crypto/evp/pmeth_gn.c

@@ -153,7 +153,7 @@ int EVP_PKEY_generate(EVP_PKEY_CTX *ctx, EVP_PKEY **ppkey)
         goto legacy;
 
     /*
-     * Asssigning gentmp to ctx->keygen_info is something our legacy
+     * Assigning gentmp to ctx->keygen_info is something our legacy
      * implementations do.  Because the provider implementations aren't
      * allowed to reach into our EVP_PKEY_CTX, we need to provide similar
      * space for backward compatibility.  It's ok that we attach a local

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>

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

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.
 

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

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

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

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.

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.

ssl/statem/statem_clnt.c

@@ -1793,7 +1793,7 @@ MSG_PROCESS_RETURN tls_process_server_hello(SSL_CONNECTION *s, PACKET *pkt)
          * If we're not doing early-data and we're not going to send a dummy CCS
          * (i.e. no middlebox compat mode) then we can change the write keys
          * immediately. Otherwise we have to defer this until after all possible
-         * early data is written. We could just alway defer until the last
+         * early data is written. We could just always defer until the last
          * moment except QUIC needs it done at the same time as the read keys
          * are changed. Since QUIC doesn't do TLS early data or need middlebox
          * compat this doesn't cause a problem.