Repository navigation
new rust implementation clnrest-rs as a drop-in replacement for clnre… - #7
Open
daywalker90 wants to merge 1 commit into
Open
daywalker90 wants to merge 1 commit into
daywalker90 wants to merge 1 commit into
Conversation
…st.py Changelog-Added: clnrest-rs available for testing as a drop-in replacement for clnrest.py
daywalker90
force-pushed
the
clnrest-rs-optional
branch
from
September 26, 2024 12:10
c124f54 to
0627df2
Compare
daywalker90
force-pushed
the
master
branch
2 times, most recently
from
March 12, 2025 12:42
d8eaa0e to
790574f
Compare
daywalker90
force-pushed
the
master
branch
3 times, most recently
from
August 11, 2025 09:34
c4d20ee to
415a7a8
Compare
rustyrussell
added a commit
that referenced
this pull request
Nov 10, 2025
And add a check for new uses creeping in, since it got cut & paste
everywhere.
This means "this is a valid string, but truncate it to this many characters"
vs "%.*s" which means "only read this many characters of string":
```
['lightningd-3 2025-10-23T02:31:40.890Z **BROKEN** plugin-funder: Plugin marked as important, shutting down lightningd!']
--------------------------- Captured stderr teardown ---------------------------
#0 0x557da58ad1dc in printf_common(void*, char const*, __va_list_tag*) asan_interceptors.cpp.o
#1 0x557da5aff814 in json_out_addv /home/runner/work/lightning/lightning/ccan/ccan/json_out/json_out.c:239:11
#2 0x557da59740ce in plugin_logv /home/runner/work/lightning/lightning/plugins/libplugin.c:1777:2
#3 0x557da5969b6f in plugin_log /home/runner/work/lightning/lightning/plugins/libplugin.c:1934:2
#4 0x557da595c4f6 in datastore_del_success /home/runner/work/lightning/lightning/plugins/funder.c:161:2
#5 0x557da598b837 in handle_rpc_reply /home/runner/work/lightning/lightning/plugins/libplugin.c:1072:10
#6 0x557da598a4b0 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1361:3
#7 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#8 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#9 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#10 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#11 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#12 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#13 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#14 0x7f6572229e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#15 0x557da588b584 in _start (/home/runner/work/lightning/lightning/plugins/funder+0x10d584) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)
0x624000009d28 is located 0 bytes to the right of 7208-byte region [0x624000008100,0x624000009d28)
allocated by thread T0 here:
#0 0x557da590e7f6 in __interceptor_realloc (/home/runner/work/lightning/lightning/plugins/funder+0x1907f6) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)
#1 0x557da5b2149b in tal_resize_ /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:755:13
#2 0x557da59f2032 in membuf_tal_resize /home/runner/work/lightning/lightning/common/utils.c:203:2
#3 0x557da5b03934 in membuf_prepare_space_ /home/runner/work/lightning/lightning/ccan/ccan/membuf/membuf.c:45:12
#4 0x557da59d4289 in jsonrpc_io_read_ /home/runner/work/lightning/lightning/common/jsonrpc_io.c:127:2
#5 0x557da598a635 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1366:9
#6 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#7 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#8 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#9 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#10 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#11 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#12 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
SUMMARY: AddressSanitizer: heap-buffer-overflow asan_interceptors.cpp.o in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
0x0c487fff9350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c487fff93a0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
0x0c487fff93b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==26122==ABORTING
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
daywalker90
pushed a commit
that referenced
this pull request
Nov 20, 2025
Changelog-None: `towire_wireaddr()` and `fromwire_wireaddr()` in `common/wireaddr.h` are responsible for marshalling/unmarshalling BOLT #7 address descriptors. Since these aren't tested by the existing wire fuzz tests, add a roundtrip test for them. This has the added benefit of testing `parse_wireaddr()` as well.
daywalker90
force-pushed
the
master
branch
2 times, most recently
from
May 27, 2026 15:01
eee7a9b to
11b8324
Compare
daywalker90
added a commit
that referenced
this pull request
Sep 28, 2026
BOLT ElementsProject#1173 made channel_update optional in UPDATE-flagged failure messages; nodes are expected to transition away from including it because applying onion-embedded updates to the gossip graph is a fingerprinting vulnerability. We already sent len=0 for private channels since 2022-02. For channeld-originated failures, rcvd_htlc_reply has been appending the channel_update *after* a message that already ended with the zero length field (since 222da7f, Oct 2023): receivers parsed len=0 and silently dropped the trailing update, so those failures were already effectively len=0 on the wire. Formalize that: always send len=0 and stop building the update for failures. Remove channel_update_for_error and channel_gossip_update_for_error. That helper also lazily disabled a channel in our own gossip when a forward failed on a disconnected peer. Preserve that behaviour explicitly (BOLT #7 allows disabling on loss of connectivity): disable in channel_gossip_channel_disconnect(), re-enable in channel_gossip_channel_reestablished(), and treat a disconnected peer as disabled in the generic channel_should_enable() callers. Tests that relied on CLN sending the update (test_pay_error_update_fees, test_xpay_error_update_fees, test_xpay_get_error_with_update and renepay's test_fees) now inject a real channel_update through an inline plugin, simulating a peer that still sends one (lnd/eclair); helpers live in tests/utils.py. test_gossip_disable_channels now actually checks the disabled/enabled bit. Receive-side compatibility with len=0 UPDATE failures (oldest safe versions): lnd: temporary_channel_failure only, since ~2017 (lightningnetwork/lnd#216, 98956bc2); other UPDATE codes still fail wire decode LDK: v0.0.115 (Apr 2023, lightningdevkit/rust-lightning#2220, 67ad6c4) for temporary_channel_failure; v0.0.124 (Sep 2024, lightningdevkit/rust-lightning#3083, 24c2468) for all UPDATE codes eclair: v0.11.0 (Dec 2024, ACINQ/eclair#2854, 414f728) CLN: 2020-06-23 (ElementsProject#3781, c100de6) application-logic safety Changelog-Changed: Protocol: onion failure messages no longer include channel_update (BOLT ElementsProject#1173).
daywalker90
added a commit
that referenced
this pull request
Sep 28, 2026
BOLT ElementsProject#1173 made channel_update optional in UPDATE-flagged failure messages; nodes are expected to transition away from including it because applying onion-embedded updates to the gossip graph is a fingerprinting vulnerability. We already sent len=0 for private channels since 2022-02. For channeld-originated failures, rcvd_htlc_reply has been appending the channel_update *after* a message that already ended with the zero length field (since 222da7f, Oct 2023): receivers parsed len=0 and silently dropped the trailing update, so those failures were already effectively len=0 on the wire. Formalize that: always send len=0 and stop building the update for failures. Remove channel_update_for_error and channel_gossip_update_for_error. That helper also lazily disabled a channel in our own gossip when a forward failed on a disconnected peer. Preserve that behaviour explicitly (BOLT #7 allows disabling on loss of connectivity): disable in channel_gossip_channel_disconnect(), re-enable in channel_gossip_channel_reestablished(), and treat a disconnected peer as disabled in the generic channel_should_enable() callers. Tests that relied on CLN sending the update (test_pay_error_update_fees, test_xpay_error_update_fees, test_xpay_get_error_with_update and renepay's test_fees) now inject a real channel_update through an inline plugin, simulating a peer that still sends one (lnd/eclair); helpers live in tests/utils.py. test_gossip_disable_channels now actually checks the disabled/enabled bit. Receive-side compatibility with len=0 UPDATE failures (oldest safe versions): lnd: temporary_channel_failure only, since ~2017 (lightningnetwork/lnd#216, 98956bc2); other UPDATE codes still fail wire decode LDK: v0.0.115 (Apr 2023, lightningdevkit/rust-lightning#2220, 67ad6c4) for temporary_channel_failure; v0.0.124 (Sep 2024, lightningdevkit/rust-lightning#3083, 24c2468) for all UPDATE codes eclair: v0.11.0 (Dec 2024, ACINQ/eclair#2854, 414f728) CLN: 2020-06-23 (ElementsProject#3781, c100de6) application-logic safety Changelog-Changed: Protocol: onion failure messages no longer include channel_update (BOLT ElementsProject#1173).
daywalker90
added a commit
that referenced
this pull request
Sep 28, 2026
BOLT ElementsProject#1173 made channel_update optional in UPDATE-flagged failure messages; nodes are expected to transition away from including it because applying onion-embedded updates to the gossip graph is a fingerprinting vulnerability. We already sent len=0 for private channels since 2022-02. For channeld-originated failures, rcvd_htlc_reply has been appending the channel_update *after* a message that already ended with the zero length field (since 222da7f, Oct 2023): receivers parsed len=0 and silently dropped the trailing update, so those failures were already effectively len=0 on the wire. Formalize that: always send len=0 and stop building the update for failures. Remove channel_update_for_error and channel_gossip_update_for_error. That helper also lazily disabled a channel in our own gossip when a forward failed on a disconnected peer. Preserve that behaviour explicitly (BOLT #7 allows disabling on loss of connectivity): disable in channel_gossip_channel_disconnect(), re-enable in channel_gossip_channel_reestablished(), and treat a disconnected peer as disabled in the generic channel_should_enable() callers. Tests that relied on CLN sending the update (test_pay_error_update_fees, test_xpay_error_update_fees, test_xpay_get_error_with_update and renepay's test_fees) now inject a real channel_update through an inline plugin, simulating a peer that still sends one (lnd/eclair); helpers live in tests/utils.py. test_gossip_disable_channels now actually checks the disabled/enabled bit. Regenerate the doc schema examples, since the listsendpays erroronion changes. Receive-side compatibility with len=0 UPDATE failures (oldest safe versions): lnd: temporary_channel_failure only, since ~2017 (lightningnetwork/lnd#216, 98956bc2); other UPDATE codes still fail wire decode LDK: v0.0.115 (Apr 2023, lightningdevkit/rust-lightning#2220, 67ad6c4) for temporary_channel_failure; v0.0.124 (Sep 2024, lightningdevkit/rust-lightning#3083, 24c2468) for all UPDATE codes eclair: v0.11.0 (Dec 2024, ACINQ/eclair#2854, 414f728) CLN: 2020-06-23 (ElementsProject#3781, c100de6) application-logic safety Changelog-Changed: Protocol: onion failure messages no longer include channel_update (BOLT ElementsProject#1173).
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…st.py
Changelog-Added: clnrest-rs available for testing as a drop-in replacement for clnrest.py
Important
Open for merging new PRs until the next PR freeze date is confirmed!
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked: