Keystone 3 firmware

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche X/P-chain derivation paths from one to ten, updates the Rust SDK dependency, and changes how signing requests extract derivation paths and fingerprints. There is no explicit security fix or vulnerability disclosure in the commit message or diff. The changes are feature-oriented, but they touch sensitive code paths (transaction signing, HD path handling, and master-fingerprint checks), so they warrant careful review.

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche (AVAX) X/P-chain account paths from one to ten, updates the Rust signing code to accept multiple derivation paths from the wallet instead of hardcoding a single one, and bumps the Rust UR registry library version. There is no explicit security fix or vulnerability patch visible in the diff; it reads as a feature/integration change.

This firmware patch changes how TON (The Open Network) wallet public keys are regenerated and how the wallet's 'manage' flag is set. Previously, TON wallets were skipped during normal public-key regeneration and were given a special 'manage' flag. The fix removes those special cases so TON wallets go through the same key-generation path as other wallets, and it prevents public-key switching for TON mnemonics. The change appears to correct a functional bug where TON wallet data could become stale or inconsistent after regenerating or switching accounts, but the commit does not describe it as a security vulnerability.

This appears to be a routine CI (Continuous Integration) configuration update with no visible security relevance. Only one file was changed with a single-line addition and deletion, and the diff content is unavailable. There is no evidence of a security fix or vulnerability.

This commit removes the special 'TON-only wallet' feature from the Keystone 3 firmware. It deletes code that let users create or import a TON-native 24-word seed phrase separate from the normal BIP39 wallet. After this change, TON is handled like other coins using a standard BIP39-derived key. There is no security bug being fixed here; it is a feature-removal cleanup.

This is a one-line change to a CI/release file titled 'chore: update ci'. No actual code changes are shown, and no security-relevant content can be identified from the available information.

This commit adds a small piece of code that writes a fixed 'magic number' marker to flash memory after a successful bootloader update. The marker is stored in the last 4 KB of the application flash region. This is likely intended as a flag so the system can later detect that a boot update has occurred. The change itself is not obviously malicious, but it modifies sensitive boot-update logic and writes to flash, so it deserves careful review in context.

This commit adds a small piece of firmware code that stores a fixed 15-byte pattern of bytes and a function that reads and mixes those bytes during device startup. On its own, the change does not appear to introduce a vulnerability; it looks like a compatibility or update-related marker. However, the purpose is not explained in the commit message, and the code is not obviously connected to any security-critical function, so its exact role is unclear from the diff alone.

This is a one-line change to a CI/release file titled 'chore: update ci'. No diff content is available, and there are no verified references suggesting security relevance. Based solely on the metadata, there is no indication this commit fixes or introduces a security issue.

This appears to be a routine CI (continuous integration) configuration update with no visible security relevance. Only one file was changed with a single-line addition and deletion. No diff content is available to inspect, and no security references were provided.

This firmware update for the Keystone 3 hardware wallet is billed as a security improvement. The most important change is a complete rewrite of the bootloader/firmware update path: it now uses SHA-256 and a signed/length-prefixed 'bootupdate' envelope instead of the older MD5-based verification, and removes an old USB mass-storage auto-reboot behavior that could let a plugged-in host trigger a reboot just by copying a file. The patch also hardens the USB stack against malformed endpoint numbers and oversized control transfers, enables on-chip flash encryption for the external QSPI flash, and improves I2C and random-number error handling. However, the diff is very large and mixes many unrelated features (new wallet icons, X Layer chain support, UI tweaks), so it is hard to be certain every corner case is fixed.

This commit removes two lines from the bootloader update code. Previously, after a successful bootloader update, the firmware erased and overwrote a sector near the end of the application flash area, then cleared a memory buffer. Now it only clears the buffer in RAM and skips the flash erase/write. This could leave stale update data or metadata in flash, potentially allowing a previously-failed or old update marker to persist and affect future boot behavior. The change is small and its security implications depend heavily on why the erase was originally performed.

This firmware update fixes a memory leak and cleans up boot-update logic in a hardware crypto wallet. The most concrete security-relevant change is adding a missing SRAM_FREE(buffer) call in BinarySearchBootHead, which prevents a small memory allocation from never being released. Other changes replace hardcoded 4096-byte values with a SECTOR_SIZE constant and remove a production-only conditional around NeedUpdateBoot. The commit message mentions 'fix memory allocation' but does not frame the change as a security fix.

This commit is described as a routine CI (continuous integration) update with only one line changed in a release-related file. No actual code changes are shown, and no security relevance is stated or visible.

This commit is a large firmware update for the Keystone 3 hardware wallet, primarily adding a bootloader update mechanism and hardening the USB stack. It introduces a way to overwrite the device's bootloader from a specially formatted region of flash memory, enables hardware-level flash encryption for production builds, and adds many bounds checks and validation routines to the USB device driver to prevent malformed host requests from crashing or confusing the device. The commit also removes the MD5 checksum code entirely and improves I2C and secure-element error handling.

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash signing code. Previously, transparent Zcash transaction signing was only enabled when the 'multi_coins' feature was active. The change also enables it when the 'cypherpunk' feature is active. Without this fix, Zcash transparent signing simply fails to compile or run in cypherpunk-only builds. There is no direct evidence in the commit of a security vulnerability; it appears to be a missing-feature bug.

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash transparent transaction signing. Previously, the code that signs the transparent (non-shielded) part of a Zcash PCZT transaction was only compiled when the 'multi_coins' feature was enabled. The change also enables that signing code when the 'cypherpunk' feature is enabled. Without this fix, a device built with only the 'cypherpunk' feature could produce an incomplete or invalid Zcash transaction signature, likely causing the transaction to be rejected by the network rather than stealing funds.

This commit adds support for a new wallet partner called Gero Wallet in the Keystone 3 firmware. It is a routine feature addition: a new icon, a new entry in wallet lists, a tutorial link, and recognition of the wallet's origin name when handling key-derivation requests. There is no indication of a security fix or vulnerability.

This commit is a build-system fix, not a security patch. It wraps a Zcash-related condition in a compile-time feature flag so that firmware builds that do not include the Web3 feature can compile. There is no direct evidence in the commit that this change fixes a vulnerability; it appears intended to restore continuous integration builds.

This commit fixes a product limitation: Keystone 3 hardware wallets using a SLIP39-style recovery phrase could not connect to the Keystone mobile app for Zcash. The patch removes Zcash from the list of coins shared when a SLIP39 wallet is used, and it makes the underlying Rust code accept a missing Zcash seed fingerprint. There is no direct evidence this is a security vulnerability; it appears to be a compatibility/functional bug fix.

This commit fixes a build-configuration bug that could prevent creating or saving public key information when using a SLIP39 passphrase. The old code accidentally skipped the normal key-derivation path for certain crypto types in non-Bitcoin-only builds, which could leave required public key data unset and cause account setup to fail. The patch restructures the conditional compilation so each build variant (Cypherpunk, Web3, Bitcoin-only) follows the correct derivation branch.

This commit is a large refactor of how the Keystone 3 firmware handles Zcash transactions. It splits the code into two build flavors: a 'multi-coins' build that supports only transparent (public) Zcash addresses using a normal xpub, and a 'cypherpunk' build that also supports shielded Orchard addresses using a unified full viewing key (UFVK). The change reorganizes feature flags, renames functions, and adjusts how Zcash account data is cached when wallets are created or unlocked. There is no explicit security fix or vulnerability disclosure in the commit message, and the diff itself is mostly structural. A few small items stand out as worth checking: a typo in a feature-guard macro (CYBERPUNK_VERSION vs CYPHERPUNK_VERSION) could leave the cypherpunk UI path disabled, and a debug printf was left in production key-handling code. On its own, this commit does not appear to introduce a clear exploitable vulnerability, but it is a partial refactor and the new multi-coins transparent-only path is simpler and exposes less shielded-key material than before.

This commit adds support for the Zcash (ZEC) cryptocurrency to the Keystone 3 hardware wallet firmware. It introduces address generation, derivation path handling, UI elements, and wallet connection data for Zcash. There is no indication of a security fix or vulnerability being patched.

This commit is a work-in-progress 'temp commit' that refactors Zcash support in the Keystone 3 firmware. It moves Zcash UI code from a 'cypherpunk' build variant into the standard multi-coin build, splits a combined Zcash UFVK/seed-fingerprint getter into separate functions, adds a new Zcash seed fingerprint parameter to the Keystone Connect wallet QR/UR generation, and enables the 'zcash' feature in the Rust multi-coins build. There is no clear security fix or vulnerability being patched; it appears to be feature plumbing and code reorganisation.

This commit adds Zcash cryptocurrency support to the Keystone 3 hardware wallet firmware. It registers a new Zcash unified full viewing key type, enables encryption of that key, wires up the user-interface handlers for Zcash transactions, and adjusts build flags so Zcash support is available in non-Bitcoin-only firmware builds. There is no direct evidence in the diff of a security vulnerability; it reads as a feature addition.