Fix new typos found by codespell

demos/guide/quic-client-block.c

@@ -203,7 +203,7 @@ int main(void)
     }
 
     if (!SSL_set_initial_peer_addr(ssl, peer_addr)) {
-        printf("Failed to set the inital peer address\n");
+        printf("Failed to set the initial peer address\n");
         goto end;
     }
 
@@ -263,7 +263,7 @@ int main(void)
     do {
         ret = SSL_shutdown(ssl);
         if (ret < 0) {
-            printf("Error shuting down: %d\n", ret);
+            printf("Error shutting down: %d\n", ret);
             goto end;
         }
     } while (ret != 1);

doc/designs/fast-param-find.md

@@ -102,10 +102,10 @@ THe top level attributes are:
   will be appended _[gs]et[_ctx]_params
 - "functions" is the functions to generate.  By default both setters and
   getters but either can be omitted.
-- "prologue" defines some introductory code emited in the generated functions.
+- "prologue" defines some introductory code emitted in the generated functions.
   Function arguments are: `void *vctx, OSSL_PARAM params[]` and this
   can be used to specialise the void pointer or declare locals.
-- "epilogue" defines some post decode code emited in the generated function
+- "epilogue" defines some post decode code emitted in the generated function
 - "params" defines the parameters both gettable and settable
 
 Within the "params" the fields specify each parameter by label.

doc/designs/quic-design/quic-api-ssl-funcs.md

@@ -835,7 +835,7 @@ Q&A For TLS-Related Calls
 QUIC always uses AES-128-GCM for Initial packets. At this time the handshake
 layer has not negotiated a ciphersuite so it has no “current” cipher. We could
 return AES-128-GCM here, but it seems reasonable to just return NULL as the
-encryption is mostly for protection against accidential modification and not
+encryption is mostly for protection against accidental modification and not
 “real” encryption. From the perspective of the Handshake layer encryption is not
 active yet. An application using QUIC can always interpret NULL as meaning
 AES-128-GCM is being used if needed as this is implied by using QUIC.

doc/designs/quic-design/quic-api.md

@@ -433,7 +433,7 @@ Should not require any changes.
 | New       | Never         | Yes       | CS            |
 
 Advances the QUIC state machine to the extent feasible, potentially performing
-network I/O. Also compatible with DTLSv1 and supercedes `DTLSv1_handle_timeout`
+network I/O. Also compatible with DTLSv1 and supersedes `DTLSv1_handle_timeout`
 for all use cases.
 
 #### `SSL_get_event_timeout`
@@ -447,7 +447,7 @@ event, if any.
 
 This is similar to the existing `DTLSv1_get_timeout` function, but it is not
 specific to DTLSv1. It is also usable for DTLSv1 and can become a
-protocol-agnostic API for this purpose, superceding `DTLSv1_get_timeout` for all
+protocol-agnostic API for this purpose, superseding `DTLSv1_get_timeout` for all
 use cases.
 
 The design is similar to that of `DTLSv1_get_timeout` and uses a `struct
@@ -1617,7 +1617,7 @@ initial call to `SSL_read` implying use of a remotely-initiated stream. However,
 this would mean we are creating state tracking a remotely-initiated stream
 before the peer has signalled it. This would work in the happy case where the
 client is connected to a compatible server but may result in strange
-inconsistencies of QUIC internal state if a client is accidentially connected to
+inconsistencies of QUIC internal state if a client is accidentally connected to
 an incompatible peer. Since the peer ought to be the authority on the streams it
 creates, this seems like an undesirable approach.
 

doc/man7/ossl-guide-quic-client-block.pod

@@ -222,7 +222,7 @@ address away for future use. Now we need to use it via the
 L<SSL_set_initial_peer_addr(3)> function.
 
     if (!SSL_set_initial_peer_addr(ssl, peer_addr)) {
-        printf("Failed to set the inital peer address\n");
+        printf("Failed to set the initial peer address\n");
         goto end;
     }
 
@@ -257,7 +257,7 @@ once:
     do {
         ret = SSL_shutdown(ssl);
         if (ret < 0) {
-            printf("Error shuting down: %d\n", ret);
+            printf("Error shutting down: %d\n", ret);
             goto end;
         }
     } while (ret != 1);

doc/man7/ossl-guide-tls-client-block.pod

@@ -78,7 +78,7 @@ can safely be set to NULL to get the default handling.
     SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
 
 In order for certificate verification to be successful you must have configured
-where the trusted certifcate store to be used is located (see
+where the trusted certificate store to be used is located (see
 L<ossl-guide-tls-introduction(7)>). In most cases you just want to use the
 default store so we call L<SSL_CTX_set_default_verify_paths(3)>.
 
@@ -95,7 +95,7 @@ L<SSL_CTX_set_min_proto_version(3)>:
 
     /*
      * TLSv1.1 or earlier are deprecated by IETF and are generally to be
-     * avoided if possible. We require a mimimum TLS version of TLSv1.2.
+     * avoided if possible. We require a minimum TLS version of TLSv1.2.
      */
     if (!SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)) {
         printf("Failed to set the minimum TLS protocol version\n");
@@ -411,7 +411,7 @@ L<SSL_get_error(3)> to determine the cause of the 0 return value.
 If L<SSL_get_error(3)> returns B<SSL_ERROR_ZERO_RETURN> then we know that the
 server has finished sending its data. Otherwise an error has occurred.
 
-=head2 Shuting down the connection
+=head2 Shutting down the connection
 
 Once we have finished reading data from the server then we are ready to close
 the connection down. We do this via the L<SSL_shutdown(3)> function which has
@@ -430,7 +430,7 @@ the server saying that we have finished writing data:
          * for one back". But we already know we got one from the peer
          * because of the SSL_ERROR_ZERO_RETURN above.
          */
-        printf("Error shuting down\n");
+        printf("Error shutting down\n");
         goto end;
     }
 
@@ -484,7 +484,7 @@ L<SSL_CTX_free(3)>.
 =head1 TROUBLESHOOTING
 
 There are a number of things that might go wrong when running the demo
-application. This section desribes some common things you might encounter.
+application. This section describes some common things you might encounter.
 
 =head2 Failure to connect the underlying socket
 
@@ -514,7 +514,7 @@ certificate store is correctly configured
 =item Unrecognised CA
 
 If the CA used by the server's certificate is not in the trusted certificate
-store for the client then this will cause a verfication failure during
+store for the client then this will cause a verification failure during
 connection. Often this can occur if the server is using a self-signed
 certificate (i.e. a test certificate that has not been signed by a CA at all).
 

doc/man7/ossl-guide-tls-introduction.pod

@@ -119,7 +119,7 @@ the server. There is a chain of trust between the root CA and the server.
 
 By default it is only the client that authenticates the server using this
 method. However it is also possible to set things up such that the server
-additionally autenticates the client. This is known as "client authentication".
+additionally authenticates the client. This is known as "client authentication".
 In this approach the client will still authenticate the server in the same way,
 but the server will request a certificate from the client. The client sends the
 server its certificate and the server authenticates it in the same way that the
@@ -215,7 +215,7 @@ object and then create multiple connections (i.e. B<SSL> objects) from it.
 Typically you can set up common configuration options on the B<SSL_CTX> so that
 all the B<SSL> object created from it inherit the same configuration options.
 
-Note that internaly to OpenSSL various items that are shared between multiple
+Note that internally to OpenSSL various items that are shared between multiple
 B<SSL> objects are cached in the B<SSL_CTX> for performance reasons. Therefore
 it is considered best practice to create one B<SSL_CTX> for use by multiple
 B<SSL> objects instead of having one B<SSL_CTX> for each B<SSL> object that you