AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 26 Bitcoin

libplugin: allow sync interface to be used at all times.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
libplugin: allow sync interface to be used at all times.

After much thought and mis-steps, I chose a simple solution: open another fd
for sync comms. It's almost impossible to know what state the async one is in.

jsonrpc_request_sync() is enhanced to return a valid tal object, as the current
behaviour of returning a pointer to inside an array was surprising.

Changelog-Changed: libplugin: you can now call the synchronous API functions at any time (not just in the init callback).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change lets Core Lightning plugins make synchronous (blocking) JSON-RPC calls at any time, not just during startup. To do that safely, it opens a second Unix socket connection to the lightningd RPC so the sync call does not collide with ongoing async traffic. The patch also fixes a memory-handling quirk so the returned response is a proper allocated object. There is no direct evidence this fixes an active security bug, but it removes a risky restriction and improves robustness.

Recommended action

Review downstream plugins that previously worked around the init-only sync restriction; verify they do not now perform blocking sync RPC calls from time-sensitive handlers. Ensure the new rpc_open path handles long rpc_location paths and connection failures safely. Consider adding fuzz or concurrency tests that exercise sync+async RPC overlap.

Security signals we found

01

Removed assert(streq(init_cmd->methodname, "init")) guards, which previously prevented use outside init

02

Added a dedicated sync RPC socket to avoid interleaving sync and async traffic on the same fd

03

Fixed surprising memory semantics where sync RPC returned a pointer into an array rather than a valid tal object

04

Changed read_rpc_reply and handle_rpc_reply signatures to pass the correct buffer offset explicitly

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 4/25
Stealth signal 3/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/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.