Electrum

This commit updates Electrum's internal CI (continuous integration) script that runs an automated security review using Anthropic's Claude Code tool. It changes the AI model version used for reviews from 'claude-opus-5' to 'claude-opus-5-5', switches the output format to a streaming JSON format, and adds detection and warning logic for cases where Claude Code silently falls back to a different (presumably weaker) model. There is no change to Electrum wallet code, cryptography, networking, or user-facing behavior.

This commit updates Electrum's own CI security-review script. It adds detection and warnings when the automated code reviewer (Claude Code) silently falls back to a different AI model, for example after a content-policy refusal. It does not change Electrum wallet code, network behavior, cryptography, or anything end users install. It is purely an internal CI/quality-assurance improvement.

This commit only adds a long code comment explaining a design choice in Electrum's PSBT-over-Nostr plugin. It does not change any program behavior. The comment documents that the plugin derives each cosigner's Nostr secret key from their Bitcoin extended public key (xpub), which means every cosigner can also compute every other cosigner's secret key. The developers explicitly call this an accepted tradeoff because the only shared cryptographic material among cosigners is the xpubs, and the Nostr keys are only used to exchange proposed transaction drafts (PSBTs). No vulnerability is introduced or fixed by this change.

Electrum's transaction builder had a bug where it would ignore certain consistency errors when fetching extra transaction data from the network. A malicious or misbehaving server could supply a wrong input amount, and Electrum would silently continue and sign the transaction with that wrong amount. The resulting transaction would be invalid and not accepted by the Bitcoin network, so no funds could be lost, but it could cause confusion, failed payments, or be used to probe wallet behavior.

This commit is a routine dependency update for the Electrum Bitcoin wallet. It bumps versions of Python, OpenSSL, secp256k1, and various Python packages used in builds and runtime. The commit itself does not fix any known security bug in Electrum's own code, nor does the project describe it as a security update. Dependency updates can indirectly improve security by including upstream bug fixes, but without specific vulnerability information we cannot say this patch is itself a security fix.

This commit is a cleanup change: it creates a single helper module for random-number generation and replaces scattered calls to os.urandom, secrets.token_bytes, and an old randrange helper with the new helpers. The new helpers still use the same Python standard-library secure random sources (os.urandom and secrets.randbelow), so the change does not introduce a security weakness. It is preparation work for a future improvement, not a fix for an active vulnerability.

This patch fixes a bug in Electrum's Lightning channel handling where a malicious or misbehaving server could trick the wallet into deleting a funded channel by claiming the funding transaction was no longer confirmed. The fix makes the wallet remember that a funding transaction was once mined and refuse to downgrade that status to 'unconfirmed,' preventing accidental loss of access to funds stored in the channel.

This commit only updates Python type hints to explicitly mark parameters and variables that can be None. It does not change any program logic, runtime behavior, or security checks. It is a code-quality and documentation improvement with no security impact.

A one-line fix changes a function so it always returns a true/false value instead of returning the raw list of signatures. The commit message says this is harmless in how Electrum currently uses it. It is a code-correctness bug, not an obvious security vulnerability.

This commit only fixes type hints in the source code. It changes annotations such as `name: str = None` to `name: str | None = None` so that developer tools correctly understand that these variables may be empty. No actual program behavior, logic, or security checks are changed.

This commit adds safety checks to Electrum's encryption helper functions and includes a self-test that runs when the program starts. The new checks make sure AES keys and initialization vectors (IVs) are the correct length before encrypting or decrypting, which helps catch programming mistakes early. The self-tests verify that hash and encryption functions produce known correct outputs, so Electrum will fail immediately if a cryptographic library is broken or misconfigured rather than silently producing bad results.

This commit adds self-tests to Electrum's cryptography code. When the program starts, it now runs a few known test vectors through hash and encryption functions and crashes immediately if the results are wrong. This is a defensive hardening change, not a fix for an active security flaw.

This change tightens validation of BIP32 master keys (the root keys used to derive all wallet addresses). Previously, Electrum would accept an extended public or private key that claimed to be a master key (depth 0) but had a non-zero child number or parent fingerprint. Such keys violate the BIP32 specification and could cause confusion or interoperability problems, but the patch is a defensive validation fix rather than a clear remote-exploitable vulnerability.

This update makes Electrum stricter when reading a BIP32 extended private key (the long encoded string that can generate all your wallet's addresses). BIP32 requires that the 33-byte private-key field start with a zero byte before the actual 32-byte secret. Electrum now rejects keys that violate this rule, which closes a gap where a malformed key could be accepted and later produce unexpected public keys or wallet behavior.

This commit tightens validation of Bitcoin wallet master keys. Under the BIP32 standard, a master key must have zero values for its 'child number' and 'parent fingerprint' fields. The change makes Electrum reject extended keys that violate this rule, preventing malformed or intentionally crafted master keys from being accepted. This is a defensive correctness fix rather than an active exploit patch.

Electrum added a check to reject malformed BIP32 extended private keys ('xprv...') where the private key data does not start with a required zero byte. Previously, such invalid keys may have been accepted. This is a defensive validation fix that prevents non-standard or corrupted keys from being processed, reducing the risk of key-handling bugs or unexpected behavior.

This commit fixes how Electrum's Trezor hardware wallet plugin handles passphrases. Previously, the code could prompt the user to enter their passphrase on the computer even when the Trezor device was configured to ask for the passphrase on the device itself. This could make users type their passphrase twice or, worse, enter a sensitive passphrase into the computer when they expected to enter it only on the device. The patch also makes the settings screen more robust when the device is locked. It is a usability and security-hardening fix rather than a remote-exploitable vulnerability.

This commit fixes a crash in Electrum's settings window for Trezor hardware wallets. After a user disabled the passphrase feature and disconnected the device, the settings dialog tried to read a value that had become 'None', causing a TypeError and crashing the dialog. The patch stores the device features before disconnecting and gracefully handles the 'None' case by showing 'Unknown' instead of crashing.

This commit fixes a bug in how Electrum talks to Trezor hardware wallets when a device setting forces passphrase entry on the Trezor itself instead of in Electrum. Previously, older Trezor devices could ask for the passphrase twice, and newer Safe 7 devices would fail to set up. The fix checks the device's setting and tells the Trezor library to handle the passphrase on the device when appropriate. It is a usability/compatibility fix, not a vulnerability patch.

This commit only updates a macOS build documentation file (README.md). It adds troubleshooting instructions for developers who are code-signing Electrum app bundles, including how to fix private-key access control and certificate trust settings. There is no code change, no wallet behavior change, and no security vulnerability being fixed.

This change tweaks a mobile-style setup wizard so that the optional passphrase text box is hidden when its checkbox is not selected, instead of merely grayed out. The commit message says this was done because users were confusing the passphrase field with the seed re-entry field. It is a usability fix, not a security bug fix.

This commit only edits the project's release notes to add a vague pre-notification that version 4.8.1 will contain undisclosed security fixes. It does not include any actual code changes, patches, or details about what the security issues are.

This commit only updates a documentation file (a README) to correct the range of Coldcard hardware wallet firmware versions affected by a previously disclosed security issue. It does not change any executable code, cryptographic logic, or wallet behavior in Electrum itself. The underlying security problem exists in Coldcard firmware, not in Electrum.

This commit is a minor logging cleanup in the mobile/QML authentication helper. It changes the wording and placement of debug/error log messages so they reveal the function name only after safely retrieving it, and avoids logging a raw tuple that could contain sensitive arguments. There is no security fix, behavior change, or vulnerability patch here.

This commit only adds a documentation warning to Electrum's Coldcard plugin README. It does not change any executable code, cryptographic logic, or wallet behavior. The warning tells users that Coldcard/Coinkite disclosed a firmware bug in certain Coldcard devices that could make on-device seeds easier to guess, and advises updating firmware and moving funds. Because Electrum itself is not being patched for a vulnerability, this commit is not a security fix for Electrum.