0.1.3 final backports

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.

[TheBlueMatt]

Built on #4710, this backports #4717, #4716, #4714, #4713, #4712, #4718, and #4719.

[ldk-reviews-bot]

I've assigned @tankyleo as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-claude-review-bot]

This continue skips not only add_channel_from_partial_announcement but also the v2 additional_data read at lines 311-319. For a version >= 2 snapshot where the channel count exceeds MAX_CHANNEL_COUNT, the trailing additional_data bytes for each skipped announcement are left unread, which misaligns read_cursor for the remainder of the snapshot (subsequent announcements and the update section parse garbage).

In practice this only triggers on an oversized (>600k channel) snapshot, where the outcome is a decode failure / rejection — so the DoS goal is still met — but for v1 the cap gracefully partial-applies whereas for v2 it corrupts parsing. Consider moving the cap check after the additional_data read (or reading the additional data before continue) so the cursor stays aligned.

[ldk-claude-review-bot]

The router.rs change is correct: overflow only occurs when at least one "next hop" exists (skip(idx + 1) non-empty), so idx + 1 is always a valid index into hops, and mark_candidate_liquidity_exhausted correctly prevents reconsideration of that path. This is a faithful backport.

I've already reviewed all files in this PR in my prior pass and posted the one inline comment that applies. No new issues found beyond what was previously flagged.

Summary

This is a backport PR of already-merged upstream fixes. I verified the adaptations are correct:

• lightning-invoice/src/lib.rs — payee-pubkey refactor has no infinite recursion (None branch calls signed_invoice.recover_payee_pub_key() directly).
• util/macro_logger.rs — DebugMsg truncation uses char_indices().nth(), slicing on a char boundary (no panic).
• util/ser.rs — cmp is imported and entry_size + 1 avoids div-by-zero for ZSTs.
• possiblyrandom/src/lib.rs — cfg logic correctly fills zeros then possibly overwrites with random.
• dns_resolution.rs — switched to byte-slice comparison, avoiding non-char-boundary panic.
• routing/router.rs — fee-overflow handling returns a valid hop index (idx + 1 is always in bounds since overflow requires a non-empty tail), fails the path cleanly instead of panicking.
• routing/gossip.rs — only visibility/doc changes for the count estimates.

Inline comments (previously posted, still applicable)

• lightning-rapid-gossip-sync/src/processing.rs:288 — the channel-count cap continue skips the v2 additional_data read (lines 311-319), misaligning read_cursor for v2 snapshots exceeding MAX_CHANNEL_COUNT. Low severity (only reachable on an oversized >600k-channel snapshot where the outcome is rejection anyway; v1 unaffected), but it corrupts v2 parsing rather than gracefully partial-applying.

No other bugs, security issues, or logic errors found.

[TheBlueMatt]

Rebased without changes.