Keystone 3 firmware

This firmware update adds support for Solana's new V1 transaction format and changes how oversized or malformed transaction details are displayed. The code introduces a dedicated parser for V1 messages with strict size and structure checks, and it prevents malformed V1 messages from being silently treated as ordinary text messages. It also paginates long transaction detail screens so users can scroll through large transactions instead of the UI breaking or truncating.

This commit is a routine build-system and code-formatting fix. It resets cached CMake build options so each build starts from known defaults, makes cbindgen header-generation failures visible instead of silently ignored, runs Rust formatting, and adds a missing import for tests. There is no indication of a security vulnerability being fixed.

This commit adds a hard cap on how many files the device will list from its SD card when loading multi-signature Bitcoin wallet data. It also tightens up null-pointer and length checks while scanning directories. The likely goal is to prevent a malicious or accidentally overstuffed SD card from crashing the wallet or causing memory corruption when it reads a huge directory listing.

This commit tightens which old-style Bitcoin-like transactions the Keystone hardware wallet will accept. It now rejects raw protobuf Bitcoin (BTC) and Dogecoin (DOGE) legacy UTXO transactions, allowing only Bitcoin Cash (BCH), Dash (DASH), and Litecoin (LTC) to keep using that older path. Bitcoin must now go through the newer PSBT route. The change is framed as a deprecation/hardening fix rather than a response to a known exploit.

This commit disables the older, raw-protobuf signing path for Bitcoin and Dogecoin transactions in the Keystone 3 hardware wallet firmware. It keeps the legacy path active only for Bitcoin Cash (BCH), Dash (DASH), and Litecoin (LTC). The change is described as a deprecation and hardening measure, not as a fix for a specific reported vulnerability. The patch adds rejection checks at multiple entry points (parsing, checking, signing, and QR-code type detection) so that unsupported legacy UTXO transactions fail with a clear error message instead of being processed.

This firmware update is a routine 'regular review fix' that hardens how the Keystone 3 hardware wallet checks and displays several cryptocurrency transactions before signing. The most important security changes are: (1) the sign button is now disabled until transaction parsing succeeds, so a malformed transaction cannot be accidentally approved; (2) Arweave/AO data-item transactions are rejected during the pre-check if their tag metadata is malformed; (3) Avalanche transactions are fully re-parsed in the pre-check, so tampered fields such as a changed output asset ID are caught; (4) Bitcoin-like fee warnings now use network-specific thresholds, so normal Dogecoin/Litecoin fees no longer trigger misleading 'large fee' alerts; and (5) Cosmos no longer shows a duplicated 'Max Fee' line, and Solana Squads proposal memos are displayed on the correct instruction. Most other changes are UI layout and cleanup.

This firmware update for the Keystone 3 hardware wallet fixes several security and safety issues found during an internal AI-assisted review. The most important changes are: (1) the signing slider is now disabled until a transaction is fully parsed, so a malformed transaction cannot be accidentally approved; (2) Arweave data-item transactions are checked for tampered tag counts before they reach the confirmation screen; (3) Avalanche transactions are fully re-parsed during the safety check so a modified transaction is rejected; (4) Bitcoin-like fee warnings now use network-specific thresholds, so Dogecoin/Litecoin users are not falsely warned or misled by Bitcoin defaults; and (5) Cosmos no longer shows a duplicated/confusing 'Max Fee' field, and Solana Squads multi-sig memos are attached to the correct instruction. Most other changes are UI clean-up.

This commit swaps out the LVGL graphics library's pseudo-random number generator for the device's hardware true random number generator (TRNG) in two places: shuffling the on-screen numeric keypad and shuffling recovery-word lists. The old code used lv_rand, which is not designed for cryptographic security and may be predictable. Using a predictable shuffle could let an attacker who can see or guess the random sequence reduce the number of possible keypad layouts or word orders they must try, weakening protections for PIN entry or seed-phrase backup verification. The patch itself is a clear improvement, but it is small and we cannot verify from the diff alone whether the TRNG driver is correctly implemented or whether other sensitive code still uses lv_rand.

This commit improves how Keystone 3's Solana app recognizes and displays certain transaction types. It adds support for the Solana Compute Budget program so those instructions are no longer labeled as 'Unknown,' and it adds parsing for Solana off-chain message signing so those messages are shown as human-readable text instead of being mistaken for raw transactions. The UI now shows unknown program addresses separately after the main transaction overview, and USB error messages can display more specific failure text. The commit title says it addresses 'Solana review findings,' but the commit message itself does not explicitly call these security fixes.

This is a large, routine code-quality and hardening patch for the Keystone 3 hardware wallet firmware. It tightens how transactions are parsed and displayed for several cryptocurrencies (Arweave, Avalanche, Bitcoin, Cosmos, Ethereum, Solana). Key user-visible effects: duplicate or malformed transaction tags are now rejected, oversized Bitcoin fees trigger a warning, unknown Cosmos messages are shown as 'blind sign' with a digest instead of being silently dropped, and Ethereum nonces/values are handled with full precision. The commit message frames this as a regular AI-assisted code review and fix, not as a response to a disclosed security incident.

This commit fixes a firmware build problem, not a runtime security bug. The Solana USB public-key service was calling a function that only exists in the multi-coin 'web3' firmware variant, so the more limited 'cypherpunk' and 'bitcoin-only' firmware variants could not compile/link. The patch makes the Solana code compile only for the web3 variant and returns an 'Unsupported coin type' error for the other variants. It is a build-configuration fix with no direct exploit path.

This commit refactors how a Solana cryptocurrency derivation path is stored while parsing a USB request. Previously, the code dynamically allocated a small heap buffer inside a helper function and returned it to the caller, which then had to free it. Now the caller provides a fixed-size stack buffer, and the helper just fills it. The change removes a potential memory leak and a use-after-free risk if the caller forgot to free the buffer, and it avoids relying on dynamic allocation for a small fixed-size string. There is no direct evidence in the commit of an exploitable vulnerability being fixed, but the change is a defensive hardening improvement.

This commit adds Solana CLI support to the Keystone 3 hardware wallet firmware. It introduces a new USB command that lets a connected computer request public keys for specific Solana derivation paths, and it reworks how USB responses are sent so they happen asynchronously rather than blocking the user interface. Most changes are feature additions and defensive hardening (for example, checking for NULL pointers and ensuring password checks are complete before approving key-derivation requests). There is no explicit security bug fix or vendor security disclosure in the commit message or diff.

This commit is a small, non-security code change. It updates a Zcash wallet test to verify that the firmware version string is preserved when account data is encoded and decoded, and it switches two Rust library dependencies from the public crates.io registry to a specific Git revision from a third-party fork. There is no direct evidence in the commit that this fixes a vulnerability.

This commit changes how the Keystone hardware wallet handles Zcash PCZT (partially-created transaction) files. Previously, after checking and signing a transaction, the device always returned the result in the newer v2 format. Now it remembers whether the incoming file was in v1 or v2 format and returns the signed result in the same version. This is a compatibility fix for wallets that only understand PCZT v1, not a fix for a vulnerability that lets an attacker steal funds.

This commit is a minor code cleanup in the Zcash shielded-transaction handling code. It removes temporary variables named `pool_label` and instead uses the existing `pool` value directly when building error messages. There is no change to security logic, transaction validation, or cryptographic operations.

This commit changes how Keystone's Zcash transaction handling treats version 6 (V6) PCZTs. Previously, all V6 Zcash transactions were rejected in the non-cypherpunk (transparent-only) code path. The patch now allows V6 transactions as long as they contain only transparent inputs and outputs, while still rejecting shielded or unknown transaction formats. This is a feature expansion to support transparent-only V6 Zcash transactions, not a fix for an active security vulnerability.

This is a simple code cleanup: three internal helper functions in the Zcash PCZT handling code are renamed to remove the word 'legacy' from their names. The actual behavior and security checks stay exactly the same. There is no functional change and no security fix or vulnerability introduced.

This commit is a small code cleanup in the Zcash transaction handling code. It replaces a custom `label()` method on the `ShieldedPool` type with Rust's standard `Display` trait, so the pool name prints the same way in error messages. There is no security-relevant change: the strings shown to users remain identical ('Orchard' and 'Ironwood'), and no transaction validation logic is altered.

This commit fixes a buffer sizing bug in the Keystone hardware wallet's Zcash support. The code previously treated the maximum string length and the buffer size as the same number, leaving no guaranteed room for the null terminator at the end of the string. In several places it also copied data using the maximum length rather than the actual buffer size. The patch adds a dedicated buffer size constant that includes space for the terminator and uses it consistently. If left unfixed, this could lead to truncated or missing terminator bytes, which in a security device can cause crashes, incorrect key handling, or in worst-case scenarios memory corruption that an attacker might exploit.

This commit only adds a changelog entry and bumps the firmware version number from 2.5.0 to 3.0.0. It contains no actual code changes, bug fixes, or security patches. The changelog mentions vague 'security policy' and 'forgot passcode' improvements, but the commit itself does not implement them.

This commit simply raises the maximum number of Zcash transactions that can be processed in one batch from 35 to 40. It updates a constant, the matching documentation, and a unit test. There is no indication of a security vulnerability being fixed.

This commit lowers the maximum number of Zcash transactions that can be processed in one batch from 40 to 35. It is a small, defensive adjustment to keep memory usage within safe limits on the hardware wallet. There is no direct evidence in the commit that this fixes an active security bug or vulnerability; it appears to be a precautionary resource-limit change.

This commit simply raises the maximum number of Zcash transactions that can be processed in one batch from 35 to 40 on a specific firmware variant. It updates a constant, the matching documentation, and a unit test. There is no indication in the commit that this fixes a security vulnerability.

This commit lowers the maximum number of Zcash transactions that can be processed in one batch from 50 to 35. It appears to be a defensive hardening change to reduce memory pressure or processing load on the hardware wallet during batch signing, rather than a fix for a known exploitable bug. There is no direct evidence in the commit or supplied references that this resolves a specific security vulnerability.