mirror of
https://github.com/openssl/openssl.git
synced 2024-11-27 03:54:14 +08:00
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:
parent
e8104bb87e
commit
6a2b8269a8
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user