wolfSSL · aidankeefe2022 · Aug 25, 2026 · Aug 25, 2026
diff --git a/.github/workflows/code-spell.yml b/.github/workflows/code-spell.yml
@@ -0,0 +1,39 @@
+name: Codespell
+
+on:
+  push:
+    branches: [ 'master' ]
+  pull_request:
+    branches: [ '*' ]
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  codespell:
+    name: Check for spelling errors
+    runs-on: ubuntu-22.04
+    timeout-minutes: 5
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Run codespell
+        uses: codespell-project/actions-codespell@v2.1
+        with:
+          check_filenames: true
+          check_hidden: true
+          # Words below are false positives, not typos:
+          #   TE            - FIPS test requirement IDs, e.g. "TE.09.09.02"
+          #   Thi           - from the example password "Thi$i$myPa$$w0rd"
+          #   regist        - parameter name in wolfMQTT (SN_Register *regist)
+          #   Writen        - Writen() wrapper from "Unix Network Programming"
+          #   Challener     - author name (Challener D., A Practical Guide to TPM 2.0)
+          #   cant          - verbatim wolfSSL error string "cant decode peer key"
+          #   mot           - Renesas skmt.exe -filetype "mot" (Motorola S-record)
+          #   callin        - verbatim wolfSentry example output
+          #   Incomming     - verbatim lwIP echoserver example output
+          #   psuedo        - verbatim wolfSSH client --help output
+          ignore_words_list: TE,Thi,inter-operability,regist,Writen,Challener,cant,mot,callin,Incomming,psuedo
+          skip: '.git'
diff --git a/wolfBoot/src-ja/appendix12.md b/wolfBoot/src-ja/appendix12.md
@@ -42,7 +42,7 @@ OPTION BYTES BANK: 0
      nRST_STOP    : 0x1 (No reset generated when entering Stop mode)
      nRST_STDBY   : 0x1 (No reset generated when entering Standby mode)
      nRST_SHDW    : 0x1 (No reset generated when entering the Shutdown mode)
-     IWDG_SW      : 0x1 (Software independant watchdog)
+     IWDG_SW      : 0x1 (Software independent watchdog)
      IWDG_STOP    : 0x1 (IWDG counter active in stop mode)
      IWDG_STDBY   : 0x1 (IWDG counter active in standby mode)
      WWDG_SW      : 0x1 (Software window watchdog)

diff --git a/wolfBoot/src/appendix12.md b/wolfBoot/src/appendix12.md
@@ -53,7 +53,7 @@ OPTION BYTES BANK: 0
      nRST_STOP    : 0x1 (No reset generated when entering Stop mode)
      nRST_STDBY   : 0x1 (No reset generated when entering Standby mode)
      nRST_SHDW    : 0x1 (No reset generated when entering the Shutdown mode)
-     IWDG_SW      : 0x1 (Software independant watchdog)
+     IWDG_SW      : 0x1 (Software independent watchdog)
      IWDG_STOP    : 0x1 (IWDG counter active in stop mode)
      IWDG_STDBY   : 0x1 (IWDG counter active in standby mode)
      WWDG_SW      : 0x1 (Software window watchdog)

diff --git a/wolfBoot/src/chapter02.md b/wolfBoot/src/chapter02.md
@@ -54,7 +54,7 @@ This is the start address of the update partition. If an external memory is used
 
  - `WOLFBOOT_PARTITION_SWAP_ADDRESS`
 
-The address for the swap spaced used by wolfBoot to swap the two firmware images in place, in order to perform a reversable update. The size of the SWAP partition is exactly one sector on the flash. If an external memory is used, the variable contains the offset of the SWAP area from the beginning of its addressable space.
+The address for the swap spaced used by wolfBoot to swap the two firmware images in place, in order to perform a reversible update. The size of the SWAP partition is exactly one sector on the flash. If an external memory is used, the variable contains the offset of the SWAP area from the beginning of its addressable space.
 
  - `WOLFBOOT_PARTITION_SIZE`
 

diff --git a/wolfBoot/src/chapter03.md b/wolfBoot/src/chapter03.md
@@ -1507,7 +1507,7 @@ c
 
 Supports K64 and K82 with crypto hardware acceleration.
 
-### Buld options
+### Build options
 
 See `/config/examples/kinetis-k82f.config` for example configuration.
 
@@ -2133,7 +2133,7 @@ Default Onboard Flash Memory Layout (2MB) (32KB sector):
 | wolfBoot          | 0xFFFF0000 | 0x00010000 ( 64 KB) |
 
 
-### Renesas Data Endianess
+### Renesas Data Endianness
 
 To switch RX parts to big endian data use:
 
@@ -2184,7 +2184,7 @@ rfp-cli -if fine -t e2l -device RX65x -auto -auth id FFFFFFFFFFFFFFFFFFFFFFFFFFF
     -run
 ```
 
-Note: Endianess: if using big endian add `-endian big`
+Note: Endianness: if using big endian add `-endian big`
 
 Note: Linux Install E2 Lite USB Driver:
 
@@ -2195,7 +2195,7 @@ sudo udevadm control --reload-rules
 
 ### Debugging Renesas RX65N
 
-Create a new "Renesas Debug" project. Choose the "E2 Lite" emulator and the built `wolfboot.elf`. After project is created open the "Debug Configuration" and change the debugger interface from "JTAG" to "FINE". Run debug and it will stop in the "reset" code in `boot_renesas_start.S`. If using Big Endian change endianess mode in "Debugger -> Debug Tool Settings -> Memory Endian -> Big Endian".
+Create a new "Renesas Debug" project. Choose the "E2 Lite" emulator and the built `wolfboot.elf`. After project is created open the "Debug Configuration" and change the debugger interface from "JTAG" to "FINE". Run debug and it will stop in the "reset" code in `boot_renesas_start.S`. If using Big Endian change endianness mode in "Debugger -> Debug Tool Settings -> Memory Endian -> Big Endian".
 
 
 ## Renesas RX72N
@@ -2298,7 +2298,7 @@ rfp-cli -if fine -t e2l -device RX72x -auto -auth id FFFFFFFFFFFFFFFFFFFFFFFFFFF
     -run
 ```
 
-Note: Endianess: if using big endian add `-endian big`
+Note: Endianness: if using big endian add `-endian big`
 
 Note: Linux Install E2 Lite USB Driver:
 

diff --git a/wolfBoot/src/chapter06.md b/wolfBoot/src/chapter06.md
@@ -319,9 +319,9 @@ wolfBoot can interact with TPM2.0 chips thanks to its integration with wolfTPM.
 
 ### Concept
 
-Typically, systems use Secure Boot to guarantee that the correct and geniune firmware is booted by verifying its signature. Afterwards, this knowledge is unknown to the sytem. The application does not know if the system started in a good known state. Sometimes, this guarantee is needed by the firmware itself. To provide such mechanism the concept of Measured Boot exist.
+Typically, systems use Secure Boot to guarantee that the correct and genuine firmware is booted by verifying its signature. Afterwards, this knowledge is unknown to the system. The application does not know if the system started in a good known state. Sometimes, this guarantee is needed by the firmware itself. To provide such mechanism the concept of Measured Boot exist.
 
-Measured Boot can be used to check every start-up component, including settings and user information(user partition). The result of the checks is then stored into special registers called PCR. This process is called PCR Extend and is refered to as a TPM measurement. PCR registers can be reset only on TPM power-on.
+Measured Boot can be used to check every start-up component, including settings and user information(user partition). The result of the checks is then stored into special registers called PCR. This process is called PCR Extend and is referred to as a TPM measurement. PCR registers can be reset only on TPM power-on.
 
 Having TPM measurements provide a way for the firmware or Operating System(OS), like Windows or Linux, to know that the software loaded before it gained control over system, is trustworthy and not modified.
 
@@ -356,7 +356,7 @@ Any TPM has a minimum of 24 PCR registers. Their typical use is as follows:
 
 Recommendations for choosing a PCR index:
 
-- During development it is recommended to use PCR16 that is intented for testing.
+- During development it is recommended to use PCR16 that is intended for testing.
 - In production, if you are running a bare-metal firmware or RTOS, you could use almost all PCRs(PCR0-15), except the one for DRTM and Trusted OS(PCR17-23).
 - If you are running Linux or Windows, PCR12-15 can be chosen for production ready firmware, in order to avoid conflict with other software that might be using PCRs from within Linux, like the Linux IMA or Microsoft Bitlocker.
 
@@ -538,7 +538,7 @@ The tool also adds all the required Tags to the image header, containing the sig
 
 wolfBoot can update itself if `RAM_CODE` is set. This procedure operates almost the same as firmware update with a few key differences. The header of the update is marked as a bootloader update (use `--wolfboot-update` for the sign tools).
 
-The new signed wolfBoot image is loaded into the UPDATE parition and triggered the same as a firmware update. Instead of performing a swap, after the image is validated and signature verified, the bootloader is erased and the new image is written to flash. This operation is _not_ safe from interruption. Interruption will prevent the device from rebooting.
+The new signed wolfBoot image is loaded into the UPDATE partition and triggered the same as a firmware update. Instead of performing a swap, after the image is validated and signature verified, the bootloader is erased and the new image is written to flash. This operation is _not_ safe from interruption. Interruption will prevent the device from rebooting.
 
 wolfBoot can be used to deploy new bootloader versions as well as update keys.
 
@@ -657,7 +657,7 @@ Encryption of external partition works at the level of the external flash interf
 
 All write calls to external partitions from the bootloader perform an additional encryption step to hide the actual content of the external non-volatile memory.
 
-Viceversa, all read operations will decrypt the data stored when the feature is enabled.
+Vice versa, all read operations will decrypt the data stored when the feature is enabled.
 
 An extra option is provided to the `sign` tool to encrypt the firmware update after signing it, so
 that it can be stored as is in the external memory by the application, and will be decrypted by the bootloader

diff --git a/wolfCLU/src/build.md b/wolfCLU/src/build.md
@@ -14,7 +14,7 @@ sudo make install
 Note that if parsing PKCS12 files with RC2 or if using CRL the flags --enable-rc2 and --enable-crl would also need to be used when building wolfSSL.
 
 
-Then build wolfCLU linking agianst the wolfSSL library created.
+Then build wolfCLU linking against the wolfSSL library created.
 
 ```
 cd wolfclu

diff --git a/wolfEngine/mkdocs.yml b/wolfEngine/mkdocs.yml
@@ -5,7 +5,7 @@ site_dir: html/
 copyright: Copyright © 2022 wolfSSL Inc.
 nav:
     - "1. Introduction": index.md
-    - "2. OpenSSL Version Compatability": chapter02.md
+    - "2. OpenSSL Version Compatibility": chapter02.md
     - "3. Building wolfEngine": chapter03.md
     - "4. FIPS 140-2 Support": chapter04.md
     - "5. Engine Control Commands": chapter05.md

diff --git a/wolfEngine/src/chapter02.md b/wolfEngine/src/chapter02.md
@@ -1,4 +1,4 @@
-# OpenSSL Version Compatability
+# OpenSSL Version Compatibility
 
 wolfEngine has been tested against the following versions of OpenSSL. wolfEngine may work with other versions, but may require some modification or adjustment:
 

diff --git a/wolfHSM/Doxyfile b/wolfHSM/Doxyfile
@@ -794,7 +794,7 @@ CITE_BIB_FILES         =
 # messages are off.
 # The default value is: NO.
 
-# TODO set to YES for upsteaming
+# TODO set to YES for upstreaming
 QUIET                  = NO
 
 # The WARNINGS tag can be used to turn on/off the warning messages that are

diff --git a/wolfMQTT/Doxyfile b/wolfMQTT/Doxyfile
@@ -794,7 +794,7 @@ CITE_BIB_FILES         =
 # messages are off.
 # The default value is: NO.
 
-# TODO set to YES for upsteaming
+# TODO set to YES for upstreaming
 QUIET                  = NO
 
 # The WARNINGS tag can be used to turn on/off the warning messages that are

diff --git a/wolfMQTT/Doxyfile-ja b/wolfMQTT/Doxyfile-ja
@@ -794,7 +794,7 @@ CITE_BIB_FILES         =
 # messages are off.
 # The default value is: NO.
 
-# TODO set to YES for upsteaming
+# TODO set to YES for upstreaming
 QUIET                  = NO
 
 # The WARNINGS tag can be used to turn on/off the warning messages that are

diff --git a/wolfProvider/mkdocs.yml b/wolfProvider/mkdocs.yml
@@ -5,7 +5,7 @@ site_dir: html/
 copyright: Copyright © 2024 wolfSSL Inc.
 nav:
     - "1. Introduction": index.md
-    - "2. OpenSSL Version Compatability": chapter02.md
+    - "2. OpenSSL Version Compatibility": chapter02.md
     - "3. Building wolfProvider": chapter03.md
     - "4. FIPS 140-3 Support": chapter04.md
     - "5. Logging": chapter05.md

diff --git a/wolfProvider/src/chapter02.md b/wolfProvider/src/chapter02.md
@@ -1,4 +1,4 @@
-# OpenSSL Version Compatability
+# OpenSSL Version Compatibility
 
 wolfProvider has been tested against the following versions of OpenSSL. wolfProvider may work with other versions, but may require some modification or adjustment:
 

diff --git a/wolfSSH/src/chapter06.md b/wolfSSH/src/chapter06.md
@@ -40,7 +40,7 @@ The example echo server implements the authentication callback with sample users
 ```
 wolfSSH_SetUserAuth(ctx, wsUserAuth);
 ```
-The example password file (passwd.txt) is a simple list of usernames and passwords seperated with a colon respectively. The defaults that exist within this file are as follows.
+The example password file (passwd.txt) is a simple list of usernames and passwords separated with a colon respectively. The defaults that exist within this file are as follows.
 
 ```   
 jill:upthehill

diff --git a/wolfSSH/src/chapter14.md b/wolfSSH/src/chapter14.md
@@ -81,7 +81,7 @@ int wolfSSH_SFTP_connect(WOLFSSH* ssh );
 WOLFSSH* ssh;
 ```
 ```
-//after creating a new WOLFSSH structrue
+//after creating a new WOLFSSH structure
 ```
 ```
 wolfSSH_SFTP_connect(ssh);

diff --git a/wolfSSL-FIPS-FAQ/src/section01.md b/wolfSSL-FIPS-FAQ/src/section01.md
@@ -1,6 +1,6 @@
 # Introduction
 
-This page lists some of the most common issues and questions that are recieved by our wolfSSL security experts, along with their responses. This FAQ is useful for solving general questions that pertain to building/implementing wolfSSL FIPS. If this page does not provide an answer to your question, please feel free to check the wolfSSL Manual, or contact us at support@wolfssl.com.
+This page lists some of the most common issues and questions that are received by our wolfSSL security experts, along with their responses. This FAQ is useful for solving general questions that pertain to building/implementing wolfSSL FIPS. If this page does not provide an answer to your question, please feel free to check the wolfSSL Manual, or contact us at support@wolfssl.com.
 
 Last Updated: 30 Mar 2026
 
@@ -15,7 +15,7 @@ Last Updated: 30 Mar 2026
 	4. [Followup Post Q: What about with fips-ready, can I use NO_ATTRIBUTE_CONSTRUCTOR with fips-ready?](./section02.md#does-the-power-on-self-test-post-really-have-to-run-every-time)
 4. [What can go wrong for the end user after basic testing?](./section02.md#what-can-go-wrong-for-the-end-user-after-basic-testing)
 5. [Moving from 140-2 to 140-3, what's new?](./section02.md#moving-from-140-2-to-140-3-whats-new)
-	1. [Will my applications that are linked agaist the 140-2 module still work with the 140-3 module?](./section02.md#will-my-app-for-1402-still-work-with-1403)
+	1. [Will my applications that are linked against the 140-2 module still work with the 140-3 module?](./section02.md#will-my-app-for-1402-still-work-with-1403)
 	2. [The wc_SetSeed_Cb() callback and the TLS Layer:](./section02.md#wc-setseed-and-tls)
 	3. [The wc_SetSeed_Cb() callback and a custom seed generation function:](./section02.md#wc-setseed-and-custom-genseed)
 	4. [The POST](./section02.md#the-post)