Skip to content

reckless: rust rewrite - #9239

Open
daywalker90 wants to merge 9 commits into
ElementsProject:masterfrom
daywalker90:reckless-rs
Open

reckless: rust rewrite#9239
daywalker90 wants to merge 9 commits into
ElementsProject:masterfrom
daywalker90:reckless-rs

Conversation

@daywalker90

Copy link
Copy Markdown
Collaborator

Not ready for code review yet, we have not decided on some important aspects. Right now it is a drop-in replacement of the python reckless version.

Should
Fixes: #8439
Fixes: #8761
Fixes: #8775
Fixes: #8776
Fixes: #8794
and should supercede #8630

Key differences:

  • it is now a plugin only, the only use case to have a standalone binary, that i could come up with, is a broken plugin install where CLN won't start, but if you can call a binary you can uncomment a line in a config, right?
  • as a consequence, alot of options are no longer necessary and reckless-dir is a proper plugin option now
  • except for the help we always output json, so no more --json option
  • the rewrite does not adhere to the reckless schema in all places, e.g. listavailable, an array of strings is just not nice here
  • a tip function was added to tip plugin authors that have an offer in their manifest.json

@daywalker90
daywalker90 force-pushed the reckless-rs branch 2 times, most recently from 8644166 to 6889d36 Compare June 19, 2026 17:21

@vincenzopalazzo vincenzopalazzo left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to see that the manifest idea is taking over. Hope you are also using git for versioning, otherwise this would be another good thing to take from https://github.com/coffee-tools/coffee

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to reference the original reference implementation https://coffee-docs.netlify.app/support-coffee

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to reference the original reference implementation https://coffee-docs.netlify.app/support-coffee

I was planning on giving full credit for the manifest/tip function to coffee in the README. But i want to lock down the functionality first before writing documentation.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to save credit was also good to just include coffee, I do not think there are more features than coffee, we were also supporting ws (palanning to) to support interactive UX inside the web applications

But these days cloning is easy!

@daywalker90

Copy link
Copy Markdown
Collaborator Author

Nice to see that the manifest idea is taking over. Hope you are also using git for versioning, otherwise this would be another good thing to take from https://github.com/coffee-tools/coffee

If you mean installing a plugin with a git ref then yes, that is supported.

@vincenzopalazzo

Copy link
Copy Markdown
Collaborator

If you mean installing a plugin with a git ref then yes, that is supported.

Yeah, otherwise it's insanity! Nice, it would be nice to have two lines that reference coffee because the development died because Blockstream was moving to reckless. Referencing a good idea is what is left in this AI era, where rebuilding is easy

@madelinevibes madelinevibes added this to the v26.09 milestone Jun 22, 2026
@daywalker90
daywalker90 force-pushed the reckless-rs branch 3 times, most recently from 6658af8 to f6bbfb5 Compare July 1, 2026 17:09
@daywalker90
daywalker90 force-pushed the reckless-rs branch 5 times, most recently from 5833d8b to 853fe7d Compare July 8, 2026 15:34
@daywalker90
daywalker90 force-pushed the reckless-rs branch 4 times, most recently from f4513c8 to bf9e3e2 Compare July 14, 2026 12:39
@daywalker90
daywalker90 marked this pull request as ready for review July 14, 2026 13:11
@daywalker90
daywalker90 requested a review from cdecker as a code owner July 14, 2026 13:11
@daywalker90

daywalker90 commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator Author

Some tests will fail for now because of #9283. If we decide not to fix it, i can do a workaround.

@madelinevibes madelinevibes added the QA Blockstream QA team have reproduced, or a test has been created! Look for the linked PR/Issue label Jul 17, 2026
Changelog-Changed: reckless: complete rewrite with new subcommands `listinstalled` and `tip`. Replaced `search` with `listavailable`.
@madelinevibes madelinevibes added the Status::Ready for Review The work has been completed and is now awaiting evaluation or approval. label Jul 23, 2026
@madelinevibes
madelinevibes requested a review from enaples July 23, 2026 07:59
return Err(anyhow!("install_cmd in manifest is empty!?"));
}

let mut cmd = Command::new(cmd_parts.first().unwrap());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

install_cmd in the reckless manifest lets any plugin repo specify a list of commands that reckless install will run on the user's node, with no confirmation prompt and no sandbox, contrary to the previous installation behaviour which only ran commands from a list of authorized installers (cargo, uv, poetry, npm, etc..).
Should we treat this kind of user-added sources differently? Would it be wise to keep this but adding a flag that explicitly allow this?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure a flag would improve security or anything. Unless something else on your machine is worth more than your node's Bitcoin and these commands could get access to that. Otherwise you already have to trust the plugin author's code to not do something nefarious like calling xpay with an offer to the plugin author's node until your balance is drained.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But isn't that a big change in code capabilities if the installation process was previously sandboxed and now is not? I'm not referring to an improper use of the node, but to potential arbitrary code execution. Is this prevented in some way I'm currently missing?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean by "change in code capabilities"? Was the python version doing something like that?

The install commands are read from the manifest.json file included in the plugin's source code. An attacker can write an attack in there or in the plugin itself. Both will run commands under the CLN user, i see no significant difference between the two.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh so this is not a new attack vettor, my bad. I must have misinterpreted how install_to_python_virtual_environment worked in the old reckless python file. I thought the provided code was somehow vetted/sandboxed. Nevermind then, I withdraw my first comment :)

}
}

match fs::remove_dir_all(&plugin_dir).await {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uninstall reclaims reckless_dir/<plugin_name> but never the cloned source repo at reckless_dir/<owner>/<repo>. Is this intended, to work as some sort of cache?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is intended. Checking out a repo can take some time so ideally we only want to do it once when the source is added. So then we also only remove it when the source is removed not a plugin belonging to that source. We would also have to check if the repo contains a single plugin or multiple for this to make sense.

If the timestamp of the python file does not differ after an update
it will load the bytecode of the old version. We remove the pycache
to make sure this does not happen. Mostly a test environment issue as
in practive the timestamps should always differ.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

QA Blockstream QA team have reproduced, or a test has been created! Look for the linked PR/Issue Status::Ready for Review The work has been completed and is now awaiting evaluation or approval.

Projects

None yet

4 participants