7.15 audit 5/6: chain integrations - #363
Conversation
THORChain, MayaChain, Osmosis, Cosmos, Binance, Ripple and EOS: - A per-chain router decides how each message family is displayed and what may be signed, replacing the single shared path where one chain's assumptions leaked into another's confirmation screens. - RUJI/TCY and other custom denominations sign correctly instead of being rendered as an unknown asset with a raw base amount. - THORChain memos are shown in full — a truncated memo hides the swap target. - Osmosis denom paging handles pools whose denom lists exceed one screen. - XRP THORChain memos use the XRPL binary Memos format so the destination actually parses on-chain. - unittests cover the router decisions, denom formatting and memo rendering for each family, including the new binance.cpp and osmosis.cpp suites.
TRON: - TIP-191 message signing (SignMessage/MessageSignature), so a TRON dapp login no longer requires signing a fabricated transaction. - USDT transfers carry a fee_limit ceiling and show a simulated fee instead of presenting an unbounded limit the user cannot evaluate. - unittests/firmware/tron.cpp covers the message prefix, the fee ceiling and contract parameter decoding. TON: - Address derivation uses sha256 over the StateInit cell rather than over the public key, which is what actually produces the wallet address.
Hive support end to end: - HiveGetPublicKey / HiveGetPublicKeys export SLIP-0048 role keys (owner, active, posting, memo) so a client can set up an account without ever seeing a private key. - HiveSignTx plus dedicated account-create and account-update flows, each confirming the operation's real effect — authority changes are shown as authority changes, not as an opaque JSON blob. - HiveSignMessage and HiveSignOperations cover the remaining wire cases, including multi-operation transactions. - Wire compatibility: canonical serialization matches what the network expects, including asset formatting and the expiration encoding. - unittests/firmware/hive.cpp covers serialization, role derivation and the confirmation text for each operation type.
|
CI queue note: this head was explicitly dispatched at https://github.com/BitHighlander/keepkey-firmware/actions/runs/31128231648 after the superseded 17-PR stack saturated the Actions queue. GitHub currently shows the jobs queued before runner assignment. The complete aggregate independently passed the CI-equivalent container suite locally: 405 firmware, 2 board, 18 crypto, and 7 Pallas constant-time tests, plus actionlint, gitleaks, the Pallas API-boundary gate, and git diff --check. |
|
Superseded by #364. Slices 04 (Zcash), 05 (chains) and 06 (Bitcoin/release security) are mutually dependent and do not compile apart: audit-04 failed every target on |
1 participant
What changed
Why
These are new chain integrations with the same audit questions: canonical parsing, complete display, derivation policy, fee disclosure, and signature binding. One chain-integration review bundle avoids three small administrative PRs while retaining per-chain commits and tests.
Validation
git diff --checkStack: 5 of 6. Review only the diff from
release/715-audit-04-zcash.