This is a minor code cleanup in the Rust Trezor client. It simplifies how the software responds when a Trezor device asks for a passphrase. The old code checked whether the device wanted the passphrase entered on the device itself; now it …
This commit removes an unused Rust helper method that checked whether a passphrase should be entered on the Trezor device. It is a routine cleanup with no visible security effect.
This commit only adds explanatory comments to existing code. It does not change any behavior. The new comments describe how encrypted lightning channel backups work in Electrum and note that the wallet's public key (xpub) is somewhat sensi…
Documentation-only changeMentions sensitivity of xpub + encrypted channel backupAdds TODO about hardened-path derived secret for future improvement
This commit fixes an out-of-memory (OOM) crash during Ethereum payment-request signing on the Trezor Safe 3 (T2B1). The fix wraps UI layout construction in a temporary async task so the device's garbage collector can reclaim memory sooner.…
Out-of-memory (OOM) crash on a hardware wallet during transaction signingFix enables earlier garbage collection of UI allocationsCrash reproducible by an existing device test for Ethereum payment requests
This commit fixes a crash bug in how rust-lightning checks DNS text records embedded in private onion messages. The old code used string slicing that could panic if a TXT record contained multi-byte characters and the prefix length landed …
panic due to non-character-boundary string slicingdenial-of-service vector via crafted onion message TXT recordBIP 353 DNSSEC resolution input validation
This commit fixes a bug in a small helper crate called `possiblyrandom` used by the Lightning Dev Kit. The crate was supposed to return real random bytes on normal operating systems, but due to a Cargo.toml misconfiguration it was silently…
Cryptographic randomness source silently disabled, producing all-zero outputConditional compilation mismatch between Cargo.toml target cfg and source feature cfgSecurity-relevant helper crate (`possiblyrandom`) used by Lightning Dev Kit
This commit fixes a minor denial-of-service issue where a malicious peer could send very long text strings inside Lightning network messages (errors, warnings, transaction aborts). Those strings were written to log files without any length…
Counterparty-controlled strings logged without length limitsInconsistent sanitization across logging sites for untrusted peer dataPotential log-file bloat / disk-filling from malicious peer messages
This commit fixes a remote denial-of-service bug in rust-lightning's LSPS (Lightning Service Provider Specification) code. An attacker could send a specially crafted date string from before 1970 (like "1900-01-01T00:00:00Z") in certain pee…
Remote-triggerable panic (DoS) via peer-controlled inputInteger conversion panic: i64 negative timestamp coerced to u64 with .expect()Input validation bypass: serde transparent deserialization skipped custom parser
This commit changes how a Bitcoin Lightning invoice library exposes the payee's public key. Previously, a function called recover_payee_pub_key always returned a public key, even when mathematically recovering it from the invoice signature…
API semantics changed from non-optional to optional return for a cryptographic recovery operationPrevious behavior could silently return an explicitly included key instead of a recovered keyNew behavior surfaces recovery failure rather than masking it
This commit fixes a bug in how Lightning payment parameters are built from BOLT11 invoices. Previously, the code always tried to recover the payee's public key from the invoice signature, even when the invoice already explicitly included t…
BOLT11 invoice payee public key derivation changed from signature recovery to explicit key preferencePaymentParameters::from_bolt11_invoice now uses get_payee_pub_key instead of recover_payee_pub_keyTest cases demonstrate handling of invoices with valid included payee key but invalid recovery ID
This commit fixes a rounding bug in a Bitcoin fee calculation. The code previously rounded the fee rate down to the nearest whole number before multiplying by transaction weight, which could cause the calculated fee to be slightly too low.…
Rounding direction changed from floor to ceil in fee computationPotential for computed fee to be slightly below required amount before fixTransaction fee insufficiency can lead to network rejection or delayed confirmation
This commit only adds a new unit test that checks how a fee rate multiplied by a transaction weight rounds up. It does not change any production code, so it cannot introduce or fix a security vulnerability by itself. It may be related to a…
A quiet fix may be responsible caution—or it may leave users unaware that their assets were ever at risk. CommitWatch preserves the evidence, adds context, and tracks whether vendors disclose, acknowledge, and learn.