Continuous public-repository analysis

Open source.
Not open secrets.

We watch what security-critical projects change—then translate the code into clear, independent intelligence anyone can understand.

23Projects watched
16924Commits captured
16841AI analyses
83High-risk findings · 30d
The watch feed

Changes worth understanding

AI analysis is published as generated. Community notes appear after human validation.

16841 analyses
Highest risk·RSS
Informational 15 AI analysisMessage 76 · Adequate
ER electrselectrs BitcoinIndexing infrastructureSoftware wallets

Bump log from 0.4.29 to 0.4.33

This is an automated dependency update by Dependabot that bumps the Rust `log` crate from version 0.4.29 to 0.4.33. The change only updates a version number and cryptographic checksum in the project's lock file. There is no indication in t…

9175b0f9by dependabot[bot]+2−21 file
No security note in commit
Low 29 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Handle `DNSSECError` messages when attempting DNSSEC resolution

This commit adds support in the Lightning Dev Kit for a new DNSSEC error message type. Previously, if a DNS resolver couldn't resolve a human-readable Lightning address, the client would simply wait and eventually time out. Now, the client…

New message handling path added for DNSSECErrorMulti-resolver query tracking with per-query blinded-path contextsPrevents a single misbehaving resolver from failing a resolution prematurely
a705abdbby Matt Corallo+205−582 files
No security note in commit
Informational 19 AI analysisMessage 81 · Strong
LDK Lightning Dev Kitrust-lightning BitcoinCryptographic librariesLightning Network

Add infrastructure for handling `DNSSECError` onion messages

This commit adds plumbing for a new Lightning onion message type called DNSSECError. It lets a DNS resolver tell a payer that a name could not be resolved, so the payer can fail or retry faster. The change is mostly new message framing and…

New network message type added with serialization/deserialization codeDefault handler is a no-op, so security relevance depends on future implementationsMessage is only processed when a valid DNSResolverContext is present
c37b0dc4by Matt Corallo+81−45 files
No security note in commit
Informational 15 AI analysisMessage 58 · Thin
BC Bitcoin CoreBitcoin Core BitcoinSupply chain

cmake: Add `GenerateWindowsInstaller` script

This commit is a build-system refactor for creating the Windows installer. It moves the NSIS installer generation logic into a separate, reusable CMake script and changes the template to use configurable directories instead of hardcoded bu…

a3b5dc05by Hennadii Stepanov+59−494 files
No security note in commit
Low 27 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Restore Zcash batch limit to 35

This commit lowers the maximum number of Zcash transactions that can be processed in one batch from 40 to 35. It is a small, defensive adjustment to keep memory usage within safe limits on the hardware wallet. There is no direct evidence i…

Resource limit reduction (batch count cap lowered)Memory safety margin adjustment for shared device memoryAtomic batch signing behavior preserved
480e0cd1by Adam Tucker+3−32 files
No security note in commit
Informational 18 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Set Zcash batch limit to 40

This commit simply raises the maximum number of Zcash transactions that can be processed in one batch from 35 to 40 on a specific firmware variant. It updates a constant, the matching documentation, and a unit test. There is no indication …

No security-relevant keywords in commit title or message.No bounds-checking, input-validation, or cryptographic code changes beyond updating the threshold value and its test.No references to CVEs, vulnerabilities, researchers, or security advisories in the commit or supplied materials.
51cae26eby Adam+3−32 files
No security note in commit
Low 32 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

pyln-proto: temporarily switch to coincurve-cp314-fix

This change swaps the project's Python cryptography dependency from the well-known 'coincurve' package to a temporary fork called 'coincurve-cp314-fix' published by an individual contributor (daywalker90). The stated reason is to fix Pytho…

Dependency switched from established package to a temporary fork with a different publisherCustom PyPI package name 'coincurve-cp314-fix' is not the upstream projectFork publisher is an individual GitHub user (daywalker90), not the original coincurve maintainers
a9c99fe2by daywalker90+49−912 files
No security note in commit
Informational 12 AI analysisMessage 75 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

renepay: add test to check for wrong CLTV computation

This commit only adds a new test case to the Core Lightning test suite. The test is marked as expected to fail (xfail) and checks whether the renepay plugin computes the CLTV (a timeout value used in Lightning payments) correctly. It does …

40a74a7fby Lagrang3+28−01 file
No security note in commit
Moderate 60 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

renepay: fix CLTV value for the first hop

This commit fixes a bug in Core Lightning's renepay plugin where the time-lock expiry (CLTV) for the first hop of a payment was incorrectly calculated by adding the current block height twice. This caused HTLCs to be created with expiry va…

CLTV/expiry miscalculation in payment routingDouble-counting of blockheight leading to far-future HTLC expiriesTest previously marked xfail now passing after fix
9181505eby Lagrang3+3−54 files
No security note in commit
Informational 15 AI analysisMessage 45 · Thin
ER electrselectrs BitcoinIndexing infrastructureSoftware wallets

Update bitcoind release in CI

This commit simply updates the version of Bitcoin Core used in the project's automated testing environment from a release candidate (31.0rc2) to the final stable release (31.1). It is a routine CI/infrastructure maintenance change with no …

eed01b98by Roman Zeyde+4−41 file
No security note in commit
Informational 15 AI analysisMessage 28 · Opaque
ER electrselectrs BitcoinIndexing infrastructureSoftware wallets

Require latest bitcoind

This commit only updates a single line in the installation documentation, changing the recommended minimum version of Bitcoin Core from 0.21+ to 31.0+. There is no code change, no bug fix, and no security patch in the diff itself.

c0a4b3faby Roman Zeyde+1−11 file
No security note in commit
01
Why commit watching?

Security should leave a paper trail.

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.

Why we built this