Fix typographical errors in .md files found by cspell

Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
This commit is contained in:
Tom Cosgrove 2022-07-29 13:44:01 +01:00
parent 27036c9e28
commit 0b86ac1957
8 changed files with 12 additions and 12 deletions

View file

@ -1,4 +1,4 @@
## Reporting Vulneratibilities ## Reporting Vulnerabilities
If you think you have found an Mbed TLS security vulnerability, then please If you think you have found an Mbed TLS security vulnerability, then please
send an email to the security team at send an email to the security team at

View file

@ -800,7 +800,7 @@ than just the MFL configuration into account.
### Relaxed semantics for PSK configuration ### Relaxed semantics for PSK configuration
This affects users which call the PSK configuration APIs This affects users which call the PSK configuration APIs
`mbedtlsl_ssl_conf_psk()` and `mbedtls_ssl_conf_psk_opaque()` `mbedtls_ssl_conf_psk()` and `mbedtls_ssl_conf_psk_opaque()`
multiple times on the same SSL configuration. multiple times on the same SSL configuration.
In Mbed TLS 2.x, users would observe later calls overwriting In Mbed TLS 2.x, users would observe later calls overwriting

View file

@ -1,4 +1,4 @@
PSA Cryptograpy API implementation and PSA driver interface PSA Cryptography API implementation and PSA driver interface
=========================================================== ===========================================================
## Introduction ## Introduction

View file

@ -171,7 +171,7 @@ match a limitation of the PSA API.
It is unclear what parameters people use in practice. It looks like by default It is unclear what parameters people use in practice. It looks like by default
OpenSSL picks saltlen = keylen - hashlen - 2 (tested with openssl 1.1.1f). OpenSSL picks saltlen = keylen - hashlen - 2 (tested with openssl 1.1.1f).
The `certool` command provided by GnuTLS seems to be picking saltlen = hashlen The `certtool` command provided by GnuTLS seems to be picking saltlen = hashlen
by default (tested with GnuTLS 3.6.13). FIPS 186-4 requires 0 <= saltlen <= by default (tested with GnuTLS 3.6.13). FIPS 186-4 requires 0 <= saltlen <=
hashlen. hashlen.

View file

@ -42,9 +42,9 @@ are:
- When `MBEDTLS_PSA_CRYPTO_C` is enabled and used, applications need to call - When `MBEDTLS_PSA_CRYPTO_C` is enabled and used, applications need to call
`psa_crypto_init()` before TLS/X.509 uses PSA functions. (This prevents us `psa_crypto_init()` before TLS/X.509 uses PSA functions. (This prevents us
from even enabling the option by default.) from even enabling the option by default.)
- `MBEDTLS_PSA_CRYPTO_C` has a hard depend on `MBEDTLS_ENTROPY_C || - `MBEDTLS_PSA_CRYPTO_C` has a hard dependency on `MBEDTLS_ENTROPY_C ||
MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG` but it's MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG` but it's
currently possible to compilte TLS and X.509 without any of the options. currently possible to compile TLS and X.509 without any of the options.
Also, we can't just auto-enable `MBEDTLS_ENTROPY_C` as it doesn't build Also, we can't just auto-enable `MBEDTLS_ENTROPY_C` as it doesn't build
out of the box on all platforms, and even less out of the box on all platforms, and even less
`MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG` as it requires a user-provided RNG `MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG` as it requires a user-provided RNG

View file

@ -241,7 +241,7 @@ The entry points that implement each step of a multi-part operation are grouped
1. The core calls the `xxx_setup` entry point for this operation family. If this fails, the core destroys the operation context object without calling any other driver entry point on it. 1. The core calls the `xxx_setup` entry point for this operation family. If this fails, the core destroys the operation context object without calling any other driver entry point on it.
1. The core calls other entry points that manipulate the operation context object, respecting the constraints. 1. The core calls other entry points that manipulate the operation context object, respecting the constraints.
1. If any entry point fails, the core calls the driver's `xxx_abort` entry point for this operation family, then destroys the operation context object without calling any other driver entry point on it. 1. If any entry point fails, the core calls the driver's `xxx_abort` entry point for this operation family, then destroys the operation context object without calling any other driver entry point on it.
1. If a “finish” entry point fails, the core destroys the operation context object without calling any other driver entry point on it. The finish entry points are: *prefix*`_mac_sign_finish`, *prefix*`_mac_verify_finish`, *prefix*`_cipher_fnish`, *prefix*`_aead_finish`, *prefix*`_aead_verify`. 1. If a “finish” entry point fails, the core destroys the operation context object without calling any other driver entry point on it. The finish entry points are: *prefix*`_mac_sign_finish`, *prefix*`_mac_verify_finish`, *prefix*`_cipher_finish`, *prefix*`_aead_finish`, *prefix*`_aead_verify`.
If a driver implements a multi-part operation but not the corresponding single-part operation, the core calls the driver's multipart operation entry points to perform the single-part operation. If a driver implements a multi-part operation but not the corresponding single-part operation, the core calls the driver's multipart operation entry points to perform the single-part operation.

View file

@ -21,7 +21,7 @@ Python3 and Jinja2 rev 2.10.1
### What's critical for a migrating user ### What's critical for a migrating user
The Driver Wrapper auto generation project is designed to use a python templating library ( Jinja2 ) to render templates based on drivers that are defined using a Driver descrioption JSON file(s). The Driver Wrapper auto generation project is designed to use a python templating library ( Jinja2 ) to render templates based on drivers that are defined using a Driver description JSON file(s).
While that is the larger goal, for version 1.0 here's what's changed While that is the larger goal, for version 1.0 here's what's changed

View file

@ -1,16 +1,16 @@
README for git hooks script README for git hooks script
=========================== ===========================
git has a way to run scripts, which are invoked by specific git commands. git has a way to run scripts, which are invoked by specific git commands.
The git hooks are located in `<mbed TLS root>/.git/hooks`, and as such are not under version control The git hooks are located in `<Mbed TLS root>/.git/hooks`, and as such are not under version control
for more information, see the [git documentation](https://git-scm.com/docs/githooks). for more information, see the [git documentation](https://git-scm.com/docs/githooks).
The mbed TLS git hooks are located in `<mbed TLS root>/tests/git-scripts` directory, and one must create a soft link from `<mbed TLS root>/.git/hooks` to `<mbed TLS root>/tesst/git-scripts`, in order to make the hook scripts successfully work. The Mbed TLS git hooks are located in `<Mbed TLS root>/tests/git-scripts` directory, and one must create a soft link from `<Mbed TLS root>/.git/hooks` to `<Mbed TLS root>/tests/git-scripts`, in order to make the hook scripts successfully work.
Example: Example:
Execute the following command to create a link on linux from the mbed TLS `.git/hooks` directory: Execute the following command to create a link on Linux from the Mbed TLS `.git/hooks` directory:
`ln -s ../../tests/git-scripts/pre-push.sh pre-push` `ln -s ../../tests/git-scripts/pre-push.sh pre-push`
**Note: Currently the mbed TLS git hooks work only on a GNU platform. If using a non-GNU platform, don't enable these hooks!** **Note: Currently the Mbed TLS git hooks work only on a GNU platform. If using a non-GNU platform, don't enable these hooks!**
These scripts can also be used independently. These scripts can also be used independently.