Keystone 3 firmware

This commit removes a weak, predictable random-number generator that was bundled as a backup inside the firmware's SLIP-39 code. Previously, if the device's proper hardware random source was accidentally left out of a build, the firmware could silently fall back to the weak generator, which would make wallet backup seeds predictable. Now the weak generator is gone for hardware builds, so a missing proper random source causes the build to fail instead of silently producing insecure seeds. The simulator still keeps a simple software-only stub for testing.

This commit simply renames the cryptocurrency token symbol from MATIC to POL in two places in the user-interface code for the Keystone 3 hardware wallet. Polygon officially rebranded its native token from MATIC to POL, so this is a routine label update. There is no security vulnerability here.

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

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 fixes a UI labeling bug in the Keystone hardware wallet's Zcash transaction review screen. Previously, when a user sent Zcash to one of their own shielded addresses (an 'external' address, not a change address), the device displayed it as if it were a payment to a stranger. Now it shows a 'Mine' tag so the user can recognize it as their own address. This is a user-experience and anti-confusion improvement, not a vulnerability that lets an attacker steal funds.

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 removes old, custom QR-code transaction formats for Bitcoin-family coins, Ethereum, and XRP, and replaces them with standardized formats. It also adds explicit rejections when the device receives a transaction through the generic 'ur:bytes' QR type for Bitcoin and Ethereum. The change is described by the vendor as a cleanup of unused protocols, but it also closes a path where a specially crafted QR code could potentially be misinterpreted as a valid transaction.

This commit upgrades the Rust compiler toolchain from one nightly version to a newer one and adjusts code to keep the project building and tests passing. It does not fix a known security bug or change how user funds are protected. Most of the file changes are new unit tests and small formatting fixes needed for the newer compiler.

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 only edits the project's changelog text. It rewrites the release notes for version 3.0.2, removing detailed bug-fix descriptions and replacing them with a shorter note about Zcash Ironwood support. No source code, build scripts, or firmware logic is changed, so this commit by itself does not introduce, fix, or alter any security behavior in the product.

This commit only changes two version numbers in a header file: the build number is increased from 1 to 2, and the beta flag is turned off (set to 0). There is no code change, no bug fix, and no security-related content in the diff or commit message.

This commit fixes a bug in a helper function that checks whether a text string is a valid hexadecimal value of the expected length. The changelog frames the user-visible fix as 'preventing Zcash public information from being regenerated on every unlock.' The code change tightens a length check so the function no longer accepts an expected length equal to the maximum buffer size, and it correctly detects strings that are exactly one character longer than the requested length. The security relevance is indirect: a malformed or over-long hex string could previously pass validation in edge cases, which might affect Zcash wallet preparation or other callers.

This commit simply switches two software building blocks (called 'crates') from a development Git snapshot to a published release version (1.0.8) on the official Rust package registry. The change itself does not add, remove, or modify any program logic in the firmware. It only changes where the code is downloaded from and which exact released version is used. There is nothing in the commit message, title, or diff that says this fixes a security problem.

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 only changes two version numbers in a header file, marking the firmware as a beta build. There are no code changes, no bug fixes, and no security-related modifications.

This commit simply updates two Rust library versions (ur-registry and ur-parse-lib) used by the Keystone 3 firmware and removes a temporary patch that pointed to a specific Git commit. There is no information in the commit itself saying this fixes a security problem, and no independent references were provided. It looks like a routine dependency maintenance change.

This commit only adds and updates test code for the Zcash PCZT (Partially-Created Zcash Transaction) feature. It hardens end-to-end test coverage for version 1 PCZTs that include both transparent and Orchard shielded inputs/outputs. There are no changes to production firmware logic, only test fixtures and test assertions.

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 tightens validation for Zcash transaction formats (PCZT) on the Keystone 3 hardware wallet. Previously, the firmware only checked that a transaction was version 6 or higher and not v6 specifically, plus that it had no Sapling or Orchard shielded components. The new code also verifies the exact transaction version, version group ID, and the consensus branch's Orchard protocol revision. A new test confirms that a v6 transaction on the Nu6 branch is rejected for transparent-only operations. The change appears to prevent unsupported or ambiguous transaction formats from being signed or parsed, which could reduce the risk of signing a transaction the wallet does not fully understand.

This commit only adds and updates test code for the Zcash cryptocurrency support in the Keystone 3 firmware. It restores an end-to-end test that exercises version 1 PCZT (Partially Created Zcash Transaction) handling for older Orchard transaction formats. There are no changes to production code, user-facing behavior, or security-sensitive logic.

This commit is a routine build update for the Zcash parts of the Keystone 3 firmware. It switches several Rust libraries from using specific GitHub revisions to using published versions from crates.io, and bumps a few version numbers. There is no direct evidence in the commit that this fixes a security vulnerability. It is primarily a dependency-maintenance change.

This commit only adds a new automated test for the Zcash cryptocurrency code. It restores test coverage to make sure that an Orchard (privacy-focused) transaction with a regular transparent output is still accepted by the validation logic. There are no changes to production code, user-facing behavior, or security-sensitive logic.

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.