Fix new typos found by codespell in documentation

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21322)
This commit is contained in:
Dimitri Papadopoulos 2023-06-29 08:55:12 +02:00 committed by Pauli
parent e8104bb87e
commit 6a2b8269a8
3 changed files with 6 additions and 6 deletions

View File

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

View File

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

View File

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