CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 20 Bitcoin

build: fix Go 1.27 compatibility

LL6b54a387 View source ↗
Public commit record

What the developer wrote

Authored by ziggie

100/100 · Strong
build: fix Go 1.27 compatibility

Upgrade the custom golangci-lint from v2.4.0 to v2.13.2 because the older
version reports false type-checking errors for generic mutex code when it
runs with Go 1.27. Refresh the tools module dependencies, account for the
renamed exhaustruct_v5 linter, and disable the deprecated gomodguard while
leaving gomodguard_v2 active.

Apply Go 1.27's gofmt output to the PSBT test's composite-literal return.

Lower the consecutive-SCID zlib test boundary from 30,794 to 30,792. Go
1.27 changed compress/flate output, making 30,793 SCIDs exceed the
65,535-byte Lightning message limit while 30,792 still fit.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a routine build-and-test maintenance patch to make the LND codebase compile and pass tests with the upcoming Go 1.27 release. It upgrades the project's custom linter tool, refreshes many indirect tool dependencies, adjusts one test's formatting, and lowers a test constant that checks how many compressed channel IDs fit in a Lightning message. There is no direct security fix here; it is a compatibility and test-hygiene change.

Recommended action

Treat as a normal build/test maintenance commit. Review the updated tool dependencies for supply-chain hygiene if desired, but no security response is indicated.

Security signals we found

01

No production code changes

02

No vulnerability fix or CVE reference present

03

Dependency-only refresh in tools module (development tooling)

04

Test constant adjusted for Go runtime compression output change

05

No mention of security relevance, researcher attribution, or advisory

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 9/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from LND

Related watches

Moderate 56 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11223 from gijswijs/legacy-dust-retribution-fix

This update fixes a bug in how LND handles old-style punishment transactions when a channel partner tries to cheat. Previously, tiny (dust) HTLCs were left as blank placeholder entries in the punishment data, which could cause the node to …

nil-pointer dereference risk in breach retribution pathlegacy revocation log handling inconsistency with modern formatdefensive hardening added for trimmed/dust HTLCs
500ca51fby ziggieXXX+168−146 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 73 · Adequate
LL Lightning LabsLND BitcoinLightning Network

Merge pull request #11190 from Roasbeef/zpay32-reject-duplicate-payment-hashes

This change tightens how LND reads Lightning invoices (BOLT 11). Previously, if an invoice contained more than one payment hash field, LND would silently keep the first one and ignore the rest. Now it rejects the invoice entirely. The rele…

Behavior change from 'use first duplicate field' to 'reject duplicate fields'New error type ErrDuplicatePaymentHash returned on duplicate payment hash fieldsMalformed/unsupported-length duplicate payment hash now treated as duplicate and rejected
86306f89by Yong+147−106 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 62 AI analysisMessage 98 · Strong
LL Lightning LabsLND BitcoinLightning Network

zpay32: reject duplicate payment hash fields

This change tightens how LND reads Lightning invoices. Previously, if an invoice contained more than one payment hash field, LND would silently keep the first valid one and ignore the rest. Now it rejects such invoices outright. This preve…

Behavioral change from silent first-field acceptance to explicit rejection of duplicate payment hash fieldsPrevents invoice parsing from depending on field ordering when multiple payment hashes are presentCovers malformed first field + valid second field, closing a potential bypass
e2f27063by Olaoluwa Osuntokun+147−106 files
Vendor flagged security relevance
Open full analysis →Source commit ↗