Keystone 3 firmware

This commit adds a validation check for Zcash PCZT (Partially Created Zcash Transaction) parsing in the Keystone hardware wallet firmware. It ensures that if an Orchard or Ironwood shielded bundle contains no actions, its declared value sum must be zero. Previously, a malformed or malicious transaction with an empty shielded bundle but a non-zero value sum might have been accepted, potentially allowing incorrect balance reporting or transaction signing.

This commit is described as a routine CI (Continuous Integration) update with only one line changed in one file. No diff content is available, and there are no verified references suggesting any security relevance. It appears to be a mundane build or release pipeline tweak.

This commit changes how the Keystone hardware wallet validates Zcash PCZT (partially-created transaction) files before signing. Previously, under a 'batch' policy it required at least one shielded input belonging to the wallet. After the change, the wallet also accepts a transaction as 'mine' if it contains an owned transparent input, even when there are no signable shielded actions. The title says the fix 'requires an owned singleton input.' The practical effect is to broaden the cases where the wallet will proceed with signing, while still rejecting transactions that have no inputs controlled by the wallet at all. The commit does not describe this as a security fix in its message, but the change is in a security-sensitive signing-check path.

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 patch changes when a Zcash batch signing screen frees a sensitive internal data structure. Instead of destroying the data immediately when the page is cleared, it now schedules the cleanup to run after the signing operation has finished. The comment in the code says this prevents the destructor from 'overtaking' the signing task, which suggests the old code could have freed memory while signing still needed it. That kind of use-after-free or premature-free bug can corrupt data or crash the device during a transaction, and in security-sensitive signing code it could theoretically affect signature correctness or leak secrets.

This commit fixes a small but meaningful bug in the Keystone hardware wallet's Zcash batch transaction screen. A 32-byte fingerprint buffer (`sfp`) was used without being initialized to zero. The code then fills it via `GetZcashSFP`, but if that function fails or does not fully write all 32 bytes, leftover memory contents could be used. In a security device, using uninitialized memory for a fingerprint/checksum can lead to incorrect verification results, unpredictable behavior, or in the worst case leak sensitive memory contents. The fix simply ensures the buffer starts as all zeros.

This is a small, defensive fix in the Zcash batch transaction screen of a Keystone hardware wallet. It adds a check that a UI display object actually exists before continuing to refresh the screen. Without the guard, the refresh function could potentially use a null (uninitialized) object, which on embedded devices can lead to a crash or undefined behavior. There is no direct evidence in the commit that this is exploitable as a security vulnerability, but null-pointer issues in firmware UI paths can sometimes be triggered by malformed transaction data and affect device availability.

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 fixes a UI text display problem where Chinese and Russian labels in the on-screen keyboard hint box could wrap awkwardly or become too long. It introduces a helper that only enables text wrapping/scrolling when the label is wider than 408 pixels. There is no direct security vulnerability in the diff; it is a cosmetic/layout fix.

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 fixes a potential memory/resource issue in the Zcash batch signing flow on the Keystone 3 hardware wallet. Before opening the signature view, the code now explicitly frees (destroys) the on-screen review widgets. Without this cleanup, the device could run low on memory or leave stale UI objects around while trying to display the signing screen, which might cause a crash or unexpected behavior during a transaction.

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.

This commit shortens translated on-screen text strings for several languages so they fit the device's user interface. It is a cosmetic localization fix with no security relevance.

This commit fixes a user-interface bug in the Bitcoin-only multi-sig wallet screens of the Keystone 3 hardware wallet firmware. If a user entered the wrong device-unlock password while the lock screen was shown over these multi-sig views, the lock screen would get stuck showing 'Verifying' instead of returning to the password entry and showing the failed-attempt count. The fix makes the wrong-password result update the lock screen, matching the correct-password path. It is a denial-of-usability issue, not a theft-of-funds vulnerability.

This commit fixes a UI bug in the Keystone 3 hardware wallet where a password-entry modal did not fully cover the screen and did not block touch input on empty areas. Because taps could pass through to buttons on the page underneath, a user might accidentally confirm or trigger an action while entering a password. The patch makes the modal cover its parent completely and marks it as clickable so it absorbs touches.

This commit is a routine font update for the Keystone 3 hardware wallet firmware. It adds, removes, and reorders Chinese, Japanese, and Korean font glyphs (for example adding characters meaning 'weak' and 'rights') and updates the corresponding translation data file. There is no code logic change and no security-relevant behavior.

This commit is a routine update of the on-device font files for multiple languages (Chinese, German, Spanish, Japanese, Korean, Russian). It adds a few new characters, tweaks some glyph bitmaps, and adjusts the generated font metadata to match newer LVGL version conventions. There is nothing in the changes that affects security, cryptography, wallet logic, or user data handling.

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash support: when a user changed their login password, the encrypted Zcash 'unified full viewing key' (UFVK) was not re-encrypted with the new password. That meant the stored UFVK could only be decrypted with the old password, which could lock the user out of Zcash functions or, in some edge cases, leave sensitive key material protected by a stale credential. The patch adds a routine to re-derive and re-encrypt the UFVK whenever the password changes, and also repairs stale ciphertext automatically at the next login.

This commit is a routine user-interface update for the Lace wallet integration. It moves the Lace wallet icon into the 'Bitcoin Wallets' submenu, removes a separate Lace entry that previously showed both Bitcoin and Cardano support, and now lists Lace only under Cardano. There is no security-relevant change in the diff.

This commit changes how a hardware crypto wallet (Keystone 3) cleans up a damaged or half-finished user account. Previously, the boot-time cleanup routine erased the account's stored pages but did not always run the same full deletion path used for normal account deletion. The patch makes the boot-time cleanup call the standard DestroyAccount function instead, so the same steps (erasing secure-element keys, clearing public info, clearing passphrase, and resetting wallet data hash) happen consistently. This reduces the chance that a partially deleted account leaves sensitive fragments behind after an unexpected reboot.

This commit adds support for a new cryptocurrency wallet called 'Lace' to the Keystone hardware wallet firmware. It includes a new icon, a new entry in the wallet list, and logic to recognize Lace as a Cardano (ADA) and Bitcoin (BTC) wallet. There is no indication of a security fix or vulnerability.