Sparrow Wallet

This commit fixes a bug in how Sparrow Wallet reads data from Keycard hardware wallets. Previously, the code trusted the length declared inside a card response without checking whether that many bytes actually exist. A malicious or malfunctioning card could claim a huge length, causing the app to read past the end of the buffer and potentially return fabricated zero-filled data. The patch now rejects responses whose declared length is truncated, oversized, or malformed, and adds tests to confirm the new behavior.

This commit fixes a bug in Sparrow Wallet's import of wallet labels. Previously, labels for multi-signature participants (keystores) could be too long or identical to each other, which could make the wallet file impossible to reopen. The change now truncates long labels and rejects duplicates during import, preventing the wallet from becoming unopenable.

This commit tightens how Sparrow Wallet handles multi-part QR codes used to import older wallet data. It limits part numbers to four digits and rejects impossible values (like part 0 of 0, or part 5 of 2). The change prevents the app from allocating huge arrays or getting confused by malformed QR frames, which could otherwise crash or freeze the wallet during a scan.

This commit hardens how Sparrow Wallet imports wallet files from other tools. It adds checks that reject malformed or inconsistent imports—such as a multisig setup that says it needs 3 signers but only provides 2 keys, or a coordinator file that would silently make the wallet derive different Bitcoin addresses than the rest of the signing group. The change is defensive: it makes the wallet refuse suspicious imports rather than accepting them.

This commit simply adds a SECURITY.md file to the repository. It is a documentation-only change that tells people how to report security bugs privately and how the project handles vulnerability disclosures. It does not change any code, fix any bug, or introduce any new feature that could affect users directly.

This commit tightens how Sparrow Wallet saves and reuses TLS certificates for private servers. Previously, any certificate that passed a basic CA check was saved as 'CA validated' even if it didn't actually match the server's hostname. That could let a malicious or misconfigured server trick the wallet into trusting the wrong certificate. Now the app also checks that the certificate's hostname matches the server, and it no longer deletes certificates that are merely 'not yet valid' (which can happen if the user's computer clock is wrong).

This commit removes several calls that tried to wipe private-key material from memory. The developer says these wipes were 'ineffective' because the underlying ECKey object still held the secret bytes. The change is a cleanup, but it slightly increases the window during which private key bytes may sit in memory. It does not introduce a remotely exploitable bug; the main risk is a small worsening of local memory-exposure hygiene.

This commit adds checks to make sure that when Sparrow Wallet asks an Electrum server for a specific Bitcoin transaction, the server actually returns the transaction that was requested. Before this change, a malicious or buggy server could return a different transaction than the one asked for, and Sparrow might trust it as if it were the right one. The fix verifies the transaction ID (a fingerprint of the transaction) matches in three places where transactions are fetched from the server.

This commit simply rotates four logo images by 90 degrees. It changes only SVG graphics files and does not touch any code, cryptography, wallet logic, or network behavior. There is no security relevance.

This commit is a routine version bump from 2.5.3 to 2.5.4. It only changes version strings in four files: the build configuration, macOS packaging metadata, in-app version constant, and documentation for reproducible builds. There are no code logic changes, bug fixes, or security-related modifications visible in the diff.

This commit tightens how Sparrow Wallet treats labels made only of spaces or tabs during wallet label import and export. Previously, a label consisting solely of whitespace was considered a real label; now it is treated as blank and skipped. The change also renames an unrelated UI field from 'useDustLimitField' to 'ignoreDustField' for clarity. There is no direct security vulnerability here, but the fix prevents minor data-quality issues and avoids surprising behavior where whitespace-only labels are exported or imported as meaningful labels.

This commit changes where Sparrow Wallet stores its files on macOS and Linux to optionally follow the XDG Base Directory Specification. It is a directory-layout migration, not a fix for a vulnerability. The change could create minor security side effects if old files remain in the previous home directory or if symlink handling during network-folder migration goes wrong, but the commit itself does not introduce an obvious exploit.

This commit fixes a rare threading bug in how Sparrow Wallet names its automatic wallet backups. The old code used a date formatter that is not safe when multiple threads use it at the same time, which could in theory produce a malformed backup filename or throw an exception. The new code uses a modern, thread-safe date formatter. There is no direct evidence this is exploitable by an attacker; it is best described as a robustness fix.

This commit hardens how Sparrow Wallet opens its encrypted wallet files. It blocks several H2 database features that could be abused to run code or read files when a malicious wallet file is opened, and it prevents Java object deserialization. It also adds tests showing that dangerous constructs like linked tables, triggers, and file-read functions are now rejected before they can execute.

This commit adds support for a new hardware wallet called ERA Wallet to the Sparrow desktop Bitcoin wallet. It is a straightforward feature addition: a new import class that reuses existing code for another similar wallet (Keystone), plus icons and menu entries. There is no indication of a security bug, vulnerability, or malicious change in the code shown.

This commit fixes a wallet-import labeling bug. When a user imported a wallet file that had been exported from a hardware-wallet-style source, Sparrow was not correctly updating the keystore's type and model to match the importer. The patch makes the import process consistently set the source and device model, and only overwrites the default label rather than any custom label the user had set. There is no direct evidence this is a security vulnerability, but mislabeling a keystore could confuse users about which device controls their funds.

This is a small follow-up patch to a security check inside Sparrow Wallet's database loader. The change tightens how the app scans a wallet file's internal database schema for dangerous commands that could let an attacker run code or link to outside data. The new version also strips out table names before checking, so attackers can't hide a dangerous command inside a cleverly named table. It appears to be a hardening fix rather than the original security fix.

This commit fixes a spelling mistake in a code comment, changing 'succesful' to 'successful'. It does not change any actual program behavior or fix any security issue.

This commit changes the build configuration for running Sparrow from an IDE (integrated development environment). It adds a JVM argument that exposes an internal Java module called 'jdk.unsupported', which contains non-standard classes like sun.misc. This is needed for some IDE debugging/profiling 'agents' to work. It slightly increases the internal Java attack surface when running in development mode, but does not change the released application that end users download.

This commit adds stronger safety checks when Sparrow Wallet opens its encrypted wallet database files. It tries to detect and block tampered wallet files that contain unusual database objects such as linked tables, triggers, aliases, synonyms, generated columns, custom domains, or unexpected default values. These checks reduce the risk that a maliciously crafted wallet file could trick the application into running harmful database commands or accessing remote data when the wallet is loaded.

This commit changes how Sparrow Wallet handles temporary files when importing or exporting wallets. Previously, temporary wallet files were created in the system's shared temporary directory, where other users or processes on the same computer could potentially read or tamper with them. The new code creates a private, owner-only temporary directory and securely deletes its contents afterward. This reduces the risk that sensitive wallet data briefly exposed during import/export could be accessed by others on the same machine.

This commit adds Gradle's dependency verification files. These files list the public keys and expected checksums for the libraries the project downloads during its build. It is a standard supply-chain hardening step, not a code change that introduces a vulnerability.

This commit swaps out the library Sparrow Wallet uses to talk to webcams. The old library used JNA (a common Java-to-native bridge), while the new one uses Java's newer Foreign Function & Memory (FFM) API. The change also adds a manual step that tries to load a native library file named openpnp-capture directly from the Java installation directory. There is no direct evidence in the commit of a security vulnerability, but any change that touches native camera access and library loading deserves a careful look because mistakes there can create ways for attackers to run malicious code or bypass sandbox protections.

This commit adds custom JSON serializers for two new types of silent-payment address classes and blocks Gson from using Java reflection on any class outside the Sparrow project. The change is defensive: it makes tests fail in the same way production would if a custom serializer were missing, which helps prevent silent data corruption or crashes when saving/loading wallet data. There is no direct evidence of an exploitable vulnerability being fixed.

This commit fixes a regression in how Sparrow Wallet saves and loads wallet data as JSON when running on newer Java versions (JDK 25). Previously, the app relied on a deep Java reflection trick to serialize certain objects, which no longer works in JDK 25. The fix removes that fragile dependency and explicitly tells the JSON library how to construct and serialize each wallet-related class. It is a compatibility/maintenance fix, not a patch for an active security vulnerability, but it touches code that handles encrypted wallet data and private-key material, so correctness matters for user safety.