rust-lightning

Pass commit context to codecov explicitly in coverage job

Codecov auto-detects only a fixed set of CI providers and cannot detect
the Forgejo Actions environment, so it fails to determine the pull
request (and commit/branch) for uploads. Pass --slug, --sha, --branch,
and --pr to the codecov CLI explicitly, derived from the workflow
context, with --pr omitted on non-pull_request events.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Comment the codecov report link on PRs

Codecov's own PR comment depends on CI environment detection, which does
not work under Forgejo, so post a link to the commit's coverage report
from the coverage job instead. A hidden marker keeps the comment sticky
(updated in place rather than re-posted on every push), and the step
only runs for pull requests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Run tor in the background for the tor-connect job

The runner image ships the tor package but has no sudo to start the
system service, so the previous `sudo apt install -y tor` step cannot
work. Instead, start tor in the background within the test step, wait
for it to fully bootstrap (the test routes real traffic, including to a
.onion address, through the proxy), run the test, and kill tor on exit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add workflow to assign a random reviewer on new PRs

Forgejo has no built-in random/round-robin reviewer assignment, so add a
small Forgejo Actions workflow that, on pull request open, picks a random
developer from the maintainer pool (excluding the author) and requests
their review via the API.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add Forgejo Actions workflows mirroring GitHub CI

Port the GitHub Actions workflows under .github/workflows/ to Forgejo
Actions under .forgejo/workflows/, targeting the instance at
git.rust-bitcoin.org and the lightningdevkit/rust-lightning repo. All
jobs run on the debian-trixie worker label; the build matrix restores
windows/macos legs (no runners provisioned for those yet).

Forgejo-specific adaptations:
- Fold the fuzz corpus push into the fuzz job, since Forgejo supports
neither the workflow_run trigger nor cross-run artifact access. The
push still targets the GitHub corpus repo and is best-effort so a
push hiccup cannot cascade to dependent jobs.
- Report build failures and stale-unicode notices via the fj CLI
against Forgejo instead of the gh CLI against GitHub.
- Run cargo audit directly in place of the rustsec/audit-check action,
which is not on Forgejo's default action registry.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Set max fee in route params for probes

May as well, and allows removing a comment that explains why we were previously
leaving it as None.

Fuzz: remove unnecessary route_params clones

Lower strictness of pending monitor update while awaiting tx_signatures

We previously assumed that no monitor update should ever be pending when
receiving `tx_signatures` while quiescent, with the exception of the
`RenegotiatedFunding` variant. This was a bit too strict, as we did not
consider that if an HTLC was sent via the same channel, its preimage
could be received from upstream leading to a monitor update to durably
persist it.

This commit ensures that if the recipient of a `tx_signatures` has not
yet echoed theirs back, and it is awaiting a monitor update completion,
then the pending monitor update must be of the `RenegotiatedFunding`
variant. If the pending monitor update is of another variant, then we
must remain quiescent with no pending updates available to send until
after the `tx_signatures` exchange.

Remove expectance of interactive-tx commitment_signed during reestablish

The use of `expecting_peer_commitment_signed` was being used as a way to
signal that we must disconnect if the message is not sent in a timely
manner. This isn't necessary, as we're already quiescent within this
flow, and can disconnect via that signal instead.

Ignore stale splice initial commitment_signed

After we complete a splice negotiation and see a
`FundingTransactionReadyForSigning` event, the counterparty may already
have sent its initial `commitment_signed` for the splice funding
transaction. If we then cancel the funding contribution, our local
channel state no longer tracks the pending splice attempt and queues
`tx_abort`, but the in-flight `commitment_signed` can still arrive
first. Handling that message against the post-abort channel state
attempts to validate a signature for the now-stale splice funding
transaction and can force-close the still-live channel.

We fix this by checking the optional `funding_txid` (which we expect all
implementations to always include by default) included in
`commitment_signed` before validating the commitment signature. If it
does not match the channel's locked funding txid, we can safely ignore
the stale message.

Avoid heap-allocating background processor futures

Replace Box::pin with core::pin::pin! in process_events_async now that
MSRV is 1.75. This eliminates a heap allocation per task on every
loop iteration by pinning the futures directly to the stack.

To satisfy lifetime and Joiner bounds, the loop logic was refactored
to run synchronous timer checks first, using flags to conditionally
execute the stack-pinned futures. Existing eager polling and early-break
semantics are preserved.

Pin zeroize for old Rust CI

zeroize 1.9.0 uses Rust 2024 metadata, which Cargo 1.75 cannot
parse. Pin it to 1.8.2 for older toolchains so the transaction sync
HTTPS feature check keeps passing on the MSRV job.

Drop the BufReader wrapper

Post `0.32.4` deserialization of consensus objects now use `Read`
as the trait bounds, making the BufReader no longer needed for
deserialization.

Deserialize consensus objects using Read type

The BufReader wrapping is no longer needed after the rust-bitcoin
`0.32.4` release which contains the standardisation of the trait
bounds for deserialization to `Read` instead of `BufReader`.

Check metadata length for bolt11 invoices

Check that the metadata when creating a bolt11 invoice is below
the bolt11 limit of 639 bytes for tagged fields.

Fix stable clippy string repeat lint

Use str::repeat in DebugMsg tests to satisfy current stable clippy.

Drop duplicate Hasher import

Simplify ChannelUnavailable APIError handling with let-else

Refactor the nested match statement used during error construction into
a more idiomatic let-else construct (stabilised in Rust 1.65). The
previous implementation required verbose, nested matching to navigate
around borrow checker limitations.

By leveraging let-else alongside chaining unwrap_err on handle_error
Result, we achieve the same teardown logic (dropping state locks)
and error mapping with significantly less boilerplate and nesting.

Format possiblyrandom cfg attributes

Run rustfmt on the possiblyrandom crate so its cfg attributes match
the current formatting rules.

Fix string slicing in TXT record validation

Rust's panicy string slicing behavior has always been a sharp edge
and here it finally caught up with us. Ensure we don't slice into
a string provided in an onion message until we're sure the index
is a character boundary.

Reported by Jordan Mecom of Block's Security Team

Get real rand in `possiblyrandom` on supported platforms w/o feat

It turns out that conditionally-enabling a dependency via `target`
in `Cargo.toml` does not enable the corresponding dependency
`feature` when compiling the code. As a result, only when building
`possiblyrandom` with an explicit `getrandom` feature did we ever
actually return random values.

This fixes this by matching the `target` cfg in `Cargo.toml` to the
cfg in `lib.rs`.

Reported by Project Loupe

Truncate logged peer message strings

Counterparty-provided strings in network messages (Error, Warning,
TxAbort) were logged without length limits, allowing a malicious peer
to bloat log files. Some logging sites also lacked the same
sanitization used for other untrusted strings.

Add a `DebugMsg` struct and `log_msg!` macro that consistently
truncate messages to 512 characters while preserving `PrintableString`
sanitization. Replace all bare `msg.data` and ad hoc
`PrintableString(&msg.data)` usages at the 7 relevant logging sites
in `peer_handler.rs` and `channel.rs`.

Co-Authored-By: HAL 9000

Reject pre-epoch `LSPSDateTime` at parse time

`LSPSDateTime::is_past` coerced `chrono`'s `i64` timestamp into a
`u64` via `try_into().expect(...)`. Because `LSPSDateTime` is parsed
from peer-controlled RFC 3339 strings (which can be pre-1970 and so
yield negative timestamps), this could be triggered remotely: an
attacker-supplied `valid_until` / `expires_at` field of e.g.
`"1900-01-01T00:00:00Z"` would parse successfully, land in LSPS state
before any HMAC / promise check, and panic the LSP thread on the next
`prune_pending_requests` sweep. Concretely reachable today via LSPS2
`opening_fee_params.valid_until` (in the buy request) and the LSPS1
expiry fields.

Make `LSPSDateTime::from_str` reject pre-epoch datetimes, and route
serde deserialization through it: `#[serde(transparent)]` was
delegating Deserialize directly to `chrono`'s impl and bypassing our
parser, so peer JSON had to be guarded separately. With both paths
funnelled through one parser, no `LSPSDateTime` value with a negative
inner timestamp can be constructed and `is_past` is safe by
construction.

Co-Authored-By: HAL 9000

Return optional recovered BOLT11 payee keys

Recovering a BOLT11 payee key can fail even when an invoice includes a
valid n field. Return the recovery result as an option and document
get_payee_pub_key as the canonical accessor.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe

Use BOLT11 invoice payee keys for payment params

Payment parameters should use the canonical payee key from BOLT11
invoices. When an invoice includes an n field, using that key avoids
attempting signature recovery that may legitimately be unavailable.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe