From 0b86ac19572566896f3cd0cc0518d95d3d1bfdb3 Mon Sep 17 00:00:00 2001 From: Tom Cosgrove Date: Fri, 29 Jul 2022 13:44:01 +0100 Subject: [PATCH] Fix typographical errors in .md files found by cspell Signed-off-by: Tom Cosgrove --- SECURITY.md | 2 +- docs/3.0-migration-guide.md | 2 +- docs/architecture/psa-crypto-implementation-structure.md | 2 +- docs/architecture/psa-migration/psa-limitations.md | 2 +- docs/architecture/psa-migration/strategy.md | 4 ++-- docs/proposed/psa-driver-interface.md | 2 +- .../psa-driver-wrappers-codegen-migration-guide.md | 2 +- tests/git-scripts/README.md | 8 ++++---- 8 files changed, 12 insertions(+), 12 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 26b77abed..33bbc2ff3 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,4 +1,4 @@ -## Reporting Vulneratibilities +## Reporting Vulnerabilities If you think you have found an Mbed TLS security vulnerability, then please send an email to the security team at diff --git a/docs/3.0-migration-guide.md b/docs/3.0-migration-guide.md index b933edfe6..884810da5 100644 --- a/docs/3.0-migration-guide.md +++ b/docs/3.0-migration-guide.md @@ -800,7 +800,7 @@ than just the MFL configuration into account. ### Relaxed semantics for PSK configuration 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. In Mbed TLS 2.x, users would observe later calls overwriting diff --git a/docs/architecture/psa-crypto-implementation-structure.md b/docs/architecture/psa-crypto-implementation-structure.md index cd4d427bf..6a0a0953c 100644 --- a/docs/architecture/psa-crypto-implementation-structure.md +++ b/docs/architecture/psa-crypto-implementation-structure.md @@ -1,4 +1,4 @@ -PSA Cryptograpy API implementation and PSA driver interface +PSA Cryptography API implementation and PSA driver interface =========================================================== ## Introduction diff --git a/docs/architecture/psa-migration/psa-limitations.md b/docs/architecture/psa-migration/psa-limitations.md index 7b8ec9929..e2efeb982 100644 --- a/docs/architecture/psa-migration/psa-limitations.md +++ b/docs/architecture/psa-migration/psa-limitations.md @@ -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 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 <= hashlen. diff --git a/docs/architecture/psa-migration/strategy.md b/docs/architecture/psa-migration/strategy.md index 883fd42a8..8d2d59fcc 100644 --- a/docs/architecture/psa-migration/strategy.md +++ b/docs/architecture/psa-migration/strategy.md @@ -42,9 +42,9 @@ are: - 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 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 - 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 out of the box on all platforms, and even less `MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG` as it requires a user-provided RNG diff --git a/docs/proposed/psa-driver-interface.md b/docs/proposed/psa-driver-interface.md index 814756200..8f02af182 100644 --- a/docs/proposed/psa-driver-interface.md +++ b/docs/proposed/psa-driver-interface.md @@ -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 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 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. diff --git a/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md b/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md index 2a10ca089..617215962 100644 --- a/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md +++ b/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md @@ -21,7 +21,7 @@ Python3 and Jinja2 rev 2.10.1 ### 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 diff --git a/tests/git-scripts/README.md b/tests/git-scripts/README.md index 29d7501b3..23db168c3 100644 --- a/tests/git-scripts/README.md +++ b/tests/git-scripts/README.md @@ -1,16 +1,16 @@ README for git hooks script =========================== git has a way to run scripts, which are invoked by specific git commands. -The git hooks are located in `/.git/hooks`, and as such are not under version control +The git hooks are located in `/.git/hooks`, and as such are not under version control for more information, see the [git documentation](https://git-scm.com/docs/githooks). -The mbed TLS git hooks are located in `/tests/git-scripts` directory, and one must create a soft link from `/.git/hooks` to `/tesst/git-scripts`, in order to make the hook scripts successfully work. +The Mbed TLS git hooks are located in `/tests/git-scripts` directory, and one must create a soft link from `/.git/hooks` to `/tests/git-scripts`, in order to make the hook scripts successfully work. 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` -**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.