Merge pull request #423 from LedgerHQ/codespell

Codespell workflow and corresponding fixes

Author: iartemov-ledger

.github/workflows/codespell.yml

@@ -0,0 +1,18 @@
+name: Misspellings CI
+
+on:
+  workflow_dispatch:
+  push:
+    branches:
+      - master
+      - main
+      - develop
+  pull_request:
+
+jobs:
+  misspell:
+    name: Check misspellings
+    uses: LedgerHQ/ledger-app-workflows/.github/workflows/reusable_spell_check.yml@v1
+    with:
+      src_path: src, bitcoin_client, bitcoin_client_js, bitcoin_client_rs, doc
+      ignore_words_list: usig,Bu,fpr

doc/bitcoin.md

@@ -65,7 +65,7 @@ Once the user approves, the `REGISTER_WALLET` returns to the client a 32-byte HM
 | 0xE000 | `SW_INTERRUPTED_EXECUTION`   | The command is interrupted, and requires the client's response |
 | 0x9000 | `SW_OK`                      | Success |
 
-<!-- TODO: add an introduction section explaining the comand reference notations (e.g. the Bitcoin style varint) -->
+<!-- TODO: add an introduction section explaining the command reference notations (e.g. the Bitcoin style varint) -->
 
 ## Commands
 
@@ -106,7 +106,7 @@ The paths defined in [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-00
 
 If the `display` parameter is `0` and the path is not standard, an error is returned.
 
-If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user. 
+If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user.
 
 ### REGISTER_WALLET
 
@@ -214,9 +214,9 @@ Given a PSBTv2 and a registered wallet (or a standard one), sign all the inputs
 | `<var>` | `global_map_size`      | The number of key/value pairs of the global map of the psbt |
 | `32`    | `global_map_keys_root` | The Merkle root of the keys of the global map |
 | `32`    | `global_map_vals_root` | The Merkle root of the values of the global map |
-| `<var>` | `n_inputs`             | The number of inputs of the psbt | 
+| `<var>` | `n_inputs`             | The number of inputs of the psbt |
 | `32`    | `inputs_maps_root`     | The Merkle root of the vector of Merkleized map commitments for the input maps |
-| `<var>` | `n_outputs`            | The number of outputs of the psbt | 
+| `<var>` | `n_outputs`            | The number of outputs of the psbt |
 | `32`    | `outputs_maps_root`    | The Merkle root of the vector of Merkleized map commitments for the output maps |
 | `32`    | `wallet_id`            | The id of the wallet |
 | `32`    | `wallet_hmac`          | The hmac of a registered wallet, or exactly 32 0 bytes |
@@ -382,7 +382,7 @@ The response must contain:
 - `1` byte: a 1-byte unsigned integer `b`, the length of the prefix of the pre-image that is part of the response;
 - `b` bytes: corresponding to the first `b` bytes of the preimage.
 
-If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one ore more `GET_MORE_ELEMENTS` requests.
+If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one or more `GET_MORE_ELEMENTS` requests.
 
 ### GET_MERKLE_LEAF_PROOF
 

doc/merkle.md

@@ -9,15 +9,15 @@ Operations on Merkle trees are composed to create commitments to more complex da
 ## Merkle trees
 ### Definition
 
-A Merkle tree allows to create a commitment to an arbitrarily large list of values; short membership proofs can be provided that can be verified solely withthe knowledge of a single hash (the Merkle tree root)
+A Merkle tree allows to create a commitment to an arbitrarily large list of values; short membership proofs can be provided that can be verified solely with the knowledge of a single hash (the Merkle tree root)
 
 Our implementation of Merkle trees loosely follow the structure defined in [RFC 6962](https://www.rfc-editor.org/rfc/pdfrfc/rfc6962.txt.pdf), using SHA-256 as the hash function. We refer to the linked document for a more detailed description. Only one difference (the hash of the empty list) is defined below.
 
 We call a *byte string* an arbitrary array of bytes, where each byte is a value between `0` and `255`. A *hash function* takes as input an arbitrary length byte string, and produces a fixed-length output. Outputs of SHA-256 are 32 bytes long.
 
 Following the notation of RFC 6962, we are given an ordered list of inputs `D[n] = {d(0), d(1), ..., d(n-1)}`, where each element `d(i)` is a byte string. We denote with `||` the concatenation operator, and with `D[a:b]` the list `{d(a), d(a+1), ..., d(b - 1)}`.
 
-We define the Merkle Tree Hash (MTH) (also called the *Merkle root*) as follows. 
+We define the Merkle Tree Hash (MTH) (also called the *Merkle root*) as follows.
 
 The hash of the empty list is `MTH({}) = 0`, a string of 32 bytes identically equal to `0`. *This definition differs from RFC 6962*.
 

doc/v0/bitcoin.md

@@ -62,7 +62,7 @@ Once the user approves, the `REGISTER_WALLET` returns to the client a 32-byte HM
 | 0xE000 | `SW_INTERRUPTED_EXECUTION`   | The command is interrupted, and requires the client's response |
 | 0x9000 | `SW_OK`                      | Success |
 
-<!-- TODO: add an introduction section explaining the comand reference notations (e.g. the Bitcoin style varint) -->
+<!-- TODO: add an introduction section explaining the command reference notations (e.g. the Bitcoin style varint) -->
 
 ## Commands
 
@@ -103,7 +103,7 @@ The paths defined in [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-00
 
 If the `display` parameter is `0` and the path is not standard, an error is returned.
 
-If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user. 
+If the `display` parameter is `1`, the result is also shown on the secure screen for verification. The UX flow shows on the device screen the exact path and the complete serialized extended pubkey as defined in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for that path. If the path is not standard, an additional warning is shown to the user.
 
 ### REGISTER_WALLET
 
@@ -209,9 +209,9 @@ Given a PSBTv2 and a registered wallet (or a standard one), sign all the inputs
 | `<var>` | `global_map_size`      | The number of key/value pairs of the global map of the psbt |
 | `32`    | `global_map_keys_root` | The Merkle root of the keys of the global map |
 | `32`    | `global_map_vals_root` | The Merkle root of the values of the global map |
-| `<var>` | `n_inputs`             | The number of inputs of the psbt | 
+| `<var>` | `n_inputs`             | The number of inputs of the psbt |
 | `32`    | `inputs_maps_root`     | The Merkle root of the vector of Merkleized map commitments for the input maps |
-| `<var>` | `n_outputs`            | The number of outputs of the psbt | 
+| `<var>` | `n_outputs`            | The number of outputs of the psbt |
 | `32`    | `outputs_maps_root`    | The Merkle root of the vector of Merkleized map commitments for the output maps |
 | `32`    | `wallet_id`            | The id of the wallet |
 | `32`    | `wallet_hmac`          | The hmac of a registered wallet, or exactly 32 0 bytes |
@@ -352,7 +352,7 @@ The response must contain:
 - `1` byte: a 1-byte unsigned integer `b`, the length of the prefix of the pre-image that is part of the response;
 - `b` bytes: corresponding to the first `b` bytes of the preimage.
 
-If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one ore more `GET_MORE_ELEMENTS` requests.
+If the pre-image is too long to be contained in a single response, the client should choose `b` to be as large as possible; subsequent bytes are enqueued as single-byte elements that the Hardware Wallet will request with one or more `GET_MORE_ELEMENTS` requests.
 
 ### GET_MERKLE_LEAF_PROOF
 
@@ -414,4 +414,4 @@ All the current commands use a commit-and-reveal approach: the APDU that starts
 - If a Merkle proof is asked via `GET_MERKLE_LEAF_PROOF`, the proof is verified.
 - If the index of a leaf is asked `GET_MERKLE_LEAF_INDEX`, the proof for that element is requested via `GET_MERKLE_LEAF_PROOF` and the proof verified, *even if the leaf value is known*.
 
-Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).
+Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).

doc/v0/wallet.md

@@ -27,9 +27,9 @@ Key placeholder `KP` expressions consist of
 - a single character `@`
 - followed by a non-negative decimal number, with no leading zeros (except for `@0`).
 
-The placeholder `@i` for some number *i* represents the *i*-th key in the vector of key orgin informations (which must be of size at least *i* + 1, or the wallet is invalid. 
+The placeholder `@i` for some number *i* represents the *i*-th key in the vector of key origin information (which must be of size at least *i* + 1, or the wallet is invalid.
 
-Each element of the *key origin informations* list is a `KEY` expression.
+Each element of the *key origin information* list is a `KEY` expression.
 `KEY` expressions:
 
 -   Key origin information, consisting of:
@@ -61,7 +61,7 @@ The app supports a number of features related to wallet policies. In order to se
 
 - register a wallet, validating all the information (policy and keys involved) with the user on the trusted screen;
 - show the addresses for a registered wallet on the trusted screen;
-- sign spends from the wallet. 
+- sign spends from the wallet.
 
 Since the application is stateless, wallet registration is not persisted on device. In order to make it possible to use a registered wallet in future requests, the device returns a hmac-sha256 (32 bytes long) for the wallet upon a successful registration. The client side is responsible for persisting the wallet policy *and* the returned hmac-sha256, and to provide this information in future requests.
 
@@ -122,4 +122,4 @@ A few policies that correspond to standardized single-key wallets can be used wi
 - ``sh(wpkh(@0))`` - nested segwit addresses as per [BIP-49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki)
 - ``tr(@0)`` - single Key P2TR as per [BIP-86](https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki)
 
-Note that the wallet policy is considered standard (and therefore usable for signing without prior registration) only if the signing paths (defined in the key origin information) adheres to the corresponding BIP.
+Note that the wallet policy is considered standard (and therefore usable for signing without prior registration) only if the signing paths (defined in the key origin information) adheres to the corresponding BIP.

doc/wallet.md

@@ -5,7 +5,7 @@ a wallet descriptor template and the vector of key placeholder expressions.
 
 A _wallet descriptor template_ follows language very similar to output descriptor, with a few differences; the biggest one is that each `KEY` expression with a key placeholder `KP` expression, that refers to one of the keys in the _keys information vector_, plus the additional derivation steps to use for that key. Contextually, the keys information vector contains all the relevant _xpubs_, and possibly their key origin information.
 
-Each entry in the key information vector contains an _xpub_ (other types of keys supported in output script descriptors are not allowed), possible preceeded by the key origin information. The key origin information is compulsory for internal keys.
+Each entry in the key information vector contains an _xpub_ (other types of keys supported in output script descriptors are not allowed), possible preceded by the key origin information. The key origin information is compulsory for internal keys.
 
 This section formally defines wallet policies, and how they relate to
 output script descriptors.
@@ -127,7 +127,7 @@ The app supports a number of features related to wallet policies. In order to se
 
 - register a wallet, validating all the information (policy and keys involved) with the user on the trusted screen;
 - show the addresses for a registered wallet on the trusted screen;
-- sign spends from the wallet. 
+- sign spends from the wallet.
 
 Since the application is stateless, wallet registration is not persisted on device. In order to make it possible to use a registered wallet in future requests, the device returns a hmac-sha256 (32 bytes long) for the wallet upon a successful registration. The client side is responsible for persisting the wallet policy *and* the returned hmac-sha256, and to provide this information in future requests.
 

src/common/merkle.h

@@ -75,10 +75,10 @@ int merkle_get_ith_direction(size_t size, size_t index, size_t i);
 /**
  * Represents the Merkleized version of a key-value map, holding the number of elements, the root of
  * the Merkle tree of the sorted list of keys, and the root of the Merkle tree of the values (sorted
- * by their correpsonding key).
+ * by their corresponding key).
  */
 typedef struct {
     uint64_t size;
     uint8_t keys_root[32];
     uint8_t values_root[32];
-} merkleized_map_commitment_t;
+} merkleized_map_commitment_t;

src/common/wallet.h

@@ -308,9 +308,9 @@ typedef enum {
 // The compiler doesn't like /** inside a block comment, so we disable this warning temporarily.
 
 /** Structure representing a key expression.
- * In V1, it's the index of a key in the key informations array, which includes the final /** step.
- * In V2, it's the index of a key in the key informations array, plus the two numbers a, b in the
- * /<NUM_a;NUM_b>/* derivation steps; here, the xpubs in the key informations array don't have extra
+ * In V1, it's the index of a key in the key information array, which includes the final /** step.
+ * In V2, it's the index of a key in the key information array, plus the two numbers a, b in the
+ * /<NUM_a;NUM_b>/* derivation steps; here, the xpubs in the key information array don't have extra
  * derivation steps.
  */
 #pragma GCC diagnostic pop

src/crypto.h

@@ -329,7 +329,7 @@ bool crypto_derive_symmetric_key(const char *label, size_t label_len, uint8_t ke
 int base58_encode_address(const uint8_t in[20], uint32_t version, char *out, size_t out_len);
 
 /**
- * Signs a SHA-256 hash using the ECDSA with deterministic nonce accordin to RFC6979; the signing
+ * Signs a SHA-256 hash using the ECDSA with deterministic nonce according to RFC6979; the signing
  * private key is the one derived at the given BIP-32 path. The signature is returned in the
  * conventional DER encoding.
  *

src/handler/lib/policy.c

@@ -417,7 +417,7 @@ execute_processor(policy_parser_state_t *state, policy_parser_processor_t proc,
 
 // p2pkh                     ==> legacy address (start with 1 on mainnet, m or n on testnet)
 // p2sh (also nested segwit) ==> legacy script  (start with 3 on mainnet, 2 on testnet)
-// p2wpkh or p2wsh           ==> bech32         (sart with bc1 on mainnet, tb1 on testnet)
+// p2wpkh or p2wsh           ==> bech32         (start with bc1 on mainnet, tb1 on testnet)
 
 // convenience function, split from get_derived_pubkey only to improve stack usage
 // returns -1 on error, 0 if the returned key info has no wildcard (**), 1 if it has the wildcard
@@ -1163,7 +1163,7 @@ int get_wallet_script(dispatcher_context_t *dispatcher_context,
         out[1] = 32;  // PUSH 32 bytes
 
         // uint8_t h[32];
-        uint8_t *h = out + 2;  // hack: re-use the output array to save memory
+        uint8_t *h = out + 2;  // hack: reuse the output array to save memory
 
         int h_length = 0;
         if (!isnull_policy_node_tree(&tr_policy->tree)) {