diff --git a/docs/architecture/adr-050-sign-mode-textual-annex2.md b/docs/architecture/adr-050-sign-mode-textual-annex2.md index ad0d5e6fd8..d4037a50e4 100644 --- a/docs/architecture/adr-050-sign-mode-textual-annex2.md +++ b/docs/architecture/adr-050-sign-mode-textual-annex2.md @@ -16,7 +16,7 @@ This annex provides normative guidance on how devices should render a ## Context `SIGN_MODE_TEXTUAL` allows a legible version of a transaction to be signed -on a hardware security devices, such as a Ledger. Early versions of the +on a hardware security device, such as a Ledger. Early versions of the design rendered transactions directly to lines of ASCII text, but this proved awkward from its in-band signaling, and for the need to display Unicode text within the transaction. @@ -53,13 +53,13 @@ sequence, with user controls for going forward or backward a line. - Expert mode screens are only presented if the device is in expert mode. - Each line of the screen starts with a number of `>` characters equal -to the screen's indetation level, followed by a `+` character if this +to the screen's indentation level, followed by a `+` character if this isn't the first line of the screen, followed by a space if either a `>` or a `+` has been emitted, or if this header is followed by a `>`, `+`, or space. -- If the line ends with whitespace or an `@` character, and `@` character -is appended to the line. +- If the line ends with whitespace or an `@` character, an additional `@` +character is appended to the line. - The following ASCII control characters or backslash (`\`) are converted to a backslash followed by a letter code, in the manner of string literals diff --git a/docs/architecture/adr-050-sign-mode-textual.md b/docs/architecture/adr-050-sign-mode-textual.md index 5e769e5f0d..b89ec2f7cf 100644 --- a/docs/architecture/adr-050-sign-mode-textual.md +++ b/docs/architecture/adr-050-sign-mode-textual.md @@ -229,7 +229,7 @@ When this option is set on a `Msg`, a registered function will transform the `Ms The `` is a string convention chosen by the application developer and is used to identify the custom `Msg` renderer. For example, the documentation or specification of this custom algorithm can reference this identifier. This identifier CAN have a versioned suffix (e.g. `_v1`) to adapt for future changes (which would be consensus-breaking). We also recommend adding Protobuf comments to describe in human language the custom logic used. -Moreover, the renderer must provide 2 functions: one for formatting from Protobuf to string, and one for parsing string to Protobuf. These 2 functions are provided by the application developer. To satisfy point #1, these 2 functions MUST be bijective with each other. Bijectivity of these 2 functions will not be checked by the SDK at runtime. However, we strongly recommend the application developer to include a comprehensive suite in their app repo to test bijectivity, as to not introduce security bugs. +Moreover, the renderer must provide 2 functions: one for formatting from Protobuf to string, and one for parsing string to Protobuf. These 2 functions are provided by the application developer. To satisfy point #1, the parse function MUST be the inverse of the formatting function. This property will not be checked by the SDK at runtime. However, we strongly recommend the application developer to include a comprehensive suite in their app repo to test invertibility, as to not introduce security bugs. ### Require signing over the `TxBody` and `AuthInfo` raw bytes @@ -244,7 +244,7 @@ where: - `HEX` is the hexadecimal representation of the bytes, all in capital letters, no `0x` prefix, - and `len()` is encoded as a Big-Endian uint64. -This is to prevent transaction hash malleability. The point #1 about bijectivity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN_MODE_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash _after_ the user signed it using SIGN_MODE_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint. +This is to prevent transaction hash malleability. The point #1 about invertiblity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN_MODE_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash _after_ the user signed it using SIGN_MODE_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint. By including this hash in the SIGN_MODE_TEXTUAL signing payload, we keep the same level of guarantees as [SIGN_MODE_DIRECT](./adr-020-protobuf-transaction-encoding.md).