Keystone 3 firmware

This commit only renames a future-work comment marker in the Zcash code from 'qr-v2-omitted-fields' to 'omitted-field-recompute'. No actual code behavior changes; it is purely a documentation-style edit to avoid confusing terminology. There is no security issue present.

This commit only reformats existing Rust code to match the project's style rules (rustfmt). No behavior, logic, or security properties of the Zcash PCZT handling changed.

This commit refactors how Keystone's Zcash signing code handles shielded transactions. It removes several old byte-level 'preflight' and 'postflight' checks and no longer passes a full viewing key (ufvk) into the final signing functions. The change appears to be a cleanup that moves verification earlier in the workflow, but the commit message and diff alone do not clearly state whether any security bug is being fixed. Without external references, it is hard to tell if this is a hardening change or just routine refactoring.

This commit changes how a Zcash hardware wallet handles batches of transactions. Previously, the signing and display code used the raw, unchecked batch data directly. After the patch, the code first runs a checking function that produces a validated 'checked batch' object, stores it, and then uses only that validated object for parsing details shown to the user and for signing. This is a defensive refactor that reduces the risk of signing a transaction that differs from what was reviewed on screen, but the commit itself does not claim to fix a specific reported vulnerability.

This commit rewrites how the Keystone hardware wallet handles Zcash batch transactions. Instead of checking each transaction message separately at every step, it now runs a single 'preflight' check that normalizes the messages, stores the checked result in a new container, and then requires that exact checked container for parsing and signing. The goal is to make sure the device signs only what it already inspected, reducing the chance that a malicious or malformed transaction slips through. The change is gated behind the 'cypherpunk' feature and only affects Zcash batch signing.

This commit adds a new Rust function for Zcash that pre-checks a batch of private (shielded) transaction data before signing. It is a feature addition with explicit safety checks and tests; the diff itself does not show a vulnerability being fixed.

This commit refactors how the Keystone hardware wallet handles Zcash transaction data. Previously, the wallet parsed and signed directly from the raw incoming transaction data. Now it first runs a 'check' function that produces a validated intermediate object (checked_PCZT), stores that object, and uses it for both on-screen display and signing. The change also adds cleanup logic to free that stored object. This is a defensive code-quality improvement that reduces the chance the wallet will display one version of a transaction but sign a different one.

This commit changes how the Keystone hardware wallet handles Zcash transactions. Previously, the wallet checked a transaction and then signed it in separate steps, with the signing step accepting any raw transaction object. Now, the check step produces a verified, normalized transaction object (a 'checked PCZT'), and the signing and parsing steps require that verified object. This is a defensive refactor designed to prevent a malicious or malformed transaction from bypassing the check step and being signed or displayed. It is a security-hardening change, not an active bug fix for a known exploit.

This commit adds a new, more efficient way to sign Zcash shielded transactions on Keystone hardware wallets. Instead of parsing and serializing the transaction multiple times, it parses once, signs in memory, and verifies signatures before returning the result. The change also preserves the checked/verified transaction data through the signing process rather than discarding it. There is no clear security bug being fixed; it appears to be a hardening and performance improvement for the Zcash cypherpunk feature.

This commit refactors Zcash PCZT (Partially-Created Zcash Transaction) handling in the Keystone hardware wallet firmware so that parsing, security checks, and re-serialization can happen in a single pass. It does not remove any existing checks; it mainly adds helper functions and a new public 'preflight' API that returns a normalized, checked version of the transaction bytes. The change appears to be a defensive code-quality improvement rather than a fix for an active vulnerability.

This commit adds a new Rust data container called ZcashCheckedPczt for the Zcash cryptocurrency support in the Keystone 3 hardware wallet firmware. It stores preflight-checked transaction bytes and a SHA-256 fingerprint (digest) so that later signing steps can verify the data has not been swapped or corrupted. It also adds a matching memory-free function for C callers. There is no bug fix or security patch here; it is a new defensive feature.

This commit adds safety checks to the bootloader update code in a cryptocurrency hardware wallet. Before the change, the firmware could trust attacker-controlled length values read from a staged update image, potentially allowing a malicious or malformed update to copy too much data, loop too many times, or write past a fixed-size buffer. The patch validates the boot image length and caps the per-loop copy size, which reduces the risk of memory corruption or unauthorized flash writes during a boot update.

This commit tightens how the Keystone hardware wallet's fingerprint sensor driver checks incoming data lengths. Before the change, the code could be tricked into reading or writing past the end of a fixed-size buffer if a malformed fingerprint message claimed a bogus length, or it could misread the length bytes and act too early. The patch adds bounds checks, resets state on bad input, and fixes a timing issue when deciding whether both length bytes have arrived. This is a defensive hardening fix for a likely buffer overflow / out-of-bounds access in interrupt-driven fingerprint UART traffic.

This commit simply adds the secure-element generation number (for example, a chip revision identifier) next to the firmware version string on three user-interface screens: the About page, the device-info page, and the welcome/setup page. It is a cosmetic display change with no security effect.

This is a large firmware commit for the Keystone 3 hardware wallet that restructures how the secure element (SE) chip is used. It introduces a generation-aware backend so the firmware can support two different SE configurations (gen-1, the current fielded design, and gen-2, a new production design) in one binary. The patch moves legacy gen-1 key derivation into its own file, adds a gen-2 backend with a different key-derivation scheme, adds lifecycle status pages so interrupted wallet create/change-PIN/delete operations can be safely resumed or erased at boot, and adds UI flows for weak-passcode warnings and a 'forget password' ownership-proof step. It also gates the legacy page-8 wipe to gen-1 only so it cannot accidentally erase gen-2 data. The commit is described by its authors as scaffolding with no runtime change for current gen-1 devices, but it does add substantial new crypto and state-machine code.

This commit updates the Zcash cryptography libraries inside the Keystone hardware wallet firmware. The main functional change is a bug fix: when the wallet tries to read encrypted Zcash note details, it now correctly chooses the decryption method for the newer 'Ironwood' (V3) notes instead of always using the older 'Orchard' (V2) method. Before this change, V3 notes could not be decrypted, which could break or mislead transactions involving the newer Zcash shielded pool. The rest of the change is dependency version bumps and test fixture adjustments.

This is a one-line build fix that changes a padding length constant from 1 to 2 in a file used only for Bitcoin-only firmware builds. There is no indication in the commit of any security issue, vulnerability, or functional bug. It appears intended solely to resolve a compilation or linker error.

This commit only adds text to two changelog files describing a new firmware version (2.5.0). It does not change any executable code, configuration, or security controls. The changelog mentions improvements to dice-roll entropy validation and unlock passcode verification, but no actual code changes are present in this commit, so it cannot introduce or fix a vulnerability on its own.

This commit only changes a single number in a version header, increasing the beta version from 1 to 2. There is no code change that affects security, functionality, or behavior of the firmware.

This commit fixes a crash in the Keystone hardware wallet when signing certain advanced Zcash transactions. The previous code used a heavy upstream signing helper that needed too much memory, causing the device to reset during an Orchard-to-Ironwood migration. The patch replaces it with a leaner, in-house signer and adds the new v6/Ironwood hash logic needed to keep signatures valid. It also rejects v6 transactions containing Sapling spends because the lean signer does not yet support that specific hash domain.

This is a tiny build-fix commit for a special feature flag called 'cypherpunk'. It changes the default Rust feature set used by developers and adds a missing 'Vec' import for Zcash code. There is nothing in the diff that alters how user funds, keys, or transactions are handled, and no security problem is visible.

This commit removes a duplicate entry in a list of internal software signal names used by the device's user interface. The duplicate would have caused the firmware to fail compilation, so the change is a straightforward build fix with no security relevance.

This commit simply switches a software dependency from a temporary community fork back to the project's own official upstream repository. The code being used is the same feature (Zcash batch registry support); it has just been merged into the official repo. There is no indication of a security problem, fix, or vulnerability.

This commit adds a new Zcash batch-signing feature for shielded transactions and fixes a UI bug where Zcash signing could freeze if the response QR code could not be generated. The changes introduce new Rust code to validate, parse, and sign batches of Zcash PCZT messages, plus new C UI screens to review and approve those batches. It also tightens error handling so that QR/USB generation failures are reported instead of leaving the device stuck. There is no direct evidence in the commit of an exploitable vulnerability, but the size and complexity of the new signing path means it should be reviewed carefully.

This commit only changes a software version number in a header file, lowering the minor version from 12.5.0 to 12.4.9 and keeping the beta flag. There is no functional code change and no security relevance visible in the diff.