radicle: init

[lorenzleutgeb]

trafficstars

Description

Radicle is a distributed code forge based on Git. I recently overhauled the package in Nixpkgs and have been using programs.radicle (for basic configuration of Radicle) and services.radicle (for managing radicle-node and radicle-http as systemd user services) for a few weeks without problems (links to my personal repo).

I could need some help with the tests. home-files/.radicle seems to be missing and I don't understand why:

$ ls -la /nix/store/afg8b60b5a79ziw03yfiwdcmmnis58l3-nmt-report-radicle-basic-configuration/tested/home-files
dr-xr-xr-x - root 1970-01-01 02:00 .cache
dr-xr-xr-x - root 1970-01-01 02:00 .config
dr-xr-xr-x - root 1970-01-01 02:00 asserts

Checklist

• [x] Change is backwards compatible. (Trivially, since there is no earlier version.)
• [x] Code formatted with ./format.
• [ ] Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.
• [ ] Test cases updated/added. See example.
• [x] Commit messages are formatted.
• [x] Added myself as module maintainer.

[ju1m]

Thanks a lot @lorenzleutgeb for the nixpkgs PR and this draft! Here's the changes I had to do to make progress https://github.com/ju1m/home-manager/commits/radicle/ Alas, with nixos-23.11's rustc, building radicle-node (after cherry-picking the nixpkgs PR) fails:

radicle-node> Found a `cargo::key=value` build directive which is reserved for future use.                                                                                                                                                                     
radicle-node> Either change the directive to `cargo:key=value` syntax (note the single `:`) or upgrade your version of Rust.                                                                                                                                   
radicle-node> See https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script for more information about build script outputs.

so I'll have to update to the upcoming nixos-24.05 before trying this further more.

[lorenzleutgeb]

Hey! Thanks for your help.

If you like, you can also try the Flake at https://github.com/lorenzleutgeb/heartwood in the meantime.

I also have things coming at https://github.com/lorenzleutgeb/radicle-nix, including more changes to the modules in this PR...

What I don't understand is why you reverted to http://github.com/lorenzleutgeb/nur ? The formatting in these files does not conform to home-manager's requirements.

[ju1m]

If you like, you can also try the Flake at https://github.com/lorenzleutgeb/heartwood in the meantime.

Thanks @lorenzleutgeb

I also have things coming at https://github.com/lorenzleutgeb/radicle-nix, including more changes to the modules in this PR...

Nice to also have a NixOS service, do you plan to open a PR to upstream it? Just in passing, something that should be checked is whether LoadCredential= can load a path from LoadCredentialEncrypted=, otherwise we may have to add some logic to support LoadCredentialEncrypted=.

What I don't understand is why you reverted to http://github.com/lorenzleutgeb/nur ? The formatting in these files does not conform to home-manager's requirements.

Well it's only after seeing that there were differences between this PR and the NUR version, and that the NUR contained two fixes (services.radicle.httpd.environnement.default's cfg.node.enable => {} and {RestartDelayMaxSec => RestartMaxDelaySec}) while looking more advanced on socket activation, that I rebased my changes on the NUR version. The formatting can always be fixed later on.

Nice to see you're actively working on this, happy to review your changes on this PR whenever you're ready to push them.

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the PR

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[matthiasbeyer]

@lorenzleutgeb please have a look at https://github.com/matthiasbeyer/home-manager/tree/radicle (git fetch https://github.com/matthiasbeyer/home-manager radicle && git checkout FETCH_HEAD) which is a rebase + fixup commits of this PR.

All patches that I think are uncontroversial are committed as --fixup commits. The others have proper commit messages.

I did not touch your initial commit, modulo the rebase changes that were necessary.

I committed my changes in a way where I think it is best if you review them commit-by-commit.

[lorenzleutgeb]

@matthiasbeyer thanks a lot! I squashed your changes in. Next I will see what CI has to say, and then integrate changes I made to my personal configuration in the meantime.

[khaneliman]

Looks like it needs nix fmt and test error:

nmt-test-radicle-basic-configuration> error: builder for '/nix/store/n8xvqw23ysn3r8n4ilaq9y8vrrsq3sl7-nmt-test-radicle-basic-configuration.drv' failed with exit code 1; last 3 log lines: > diff: /nix/store/jcvkswcb12lvgsrrdnb97rqjwnfjhd18-home-manager-generation/home-files/.radicle/config.json: No such file or directory > Expected home-files/.radicle/config.json to be same as /nix/store/39gc85n30s5qsij1dn620qabzpwl29jb-basic-configuration.json but were different:

building '/nix/store/kk86pr5r64snk8gf7lgsb1n713rrc9i9-home-manager-files.drv'... options.json> error: option programs.radicle.environment has no description options.json> error: option programs.radicle.httpd.args has no description options.json> error: option programs.radicle.node.args has no description options.json> error: option programs.radicle.settings has no description options.json> error: option programs.radicle.settings.cli has no description options.json> error: option programs.radicle.settings.cli.hints has no description options.json> error: option programs.radicle.settings.node has no description options.json> error: option programs.radicle.settings.node.alias has no description options.json> error: option programs.radicle.settings.node.network has no description options.json> error: option programs.radicle.settings.node.peers has no description options.json> error: option programs.radicle.settings.node.peers.target has no description options.json> error: option programs.radicle.settings.node.peers.type has no description options.json> error: option programs.radicle.settings.node.policy has no description options.json> error: option programs.radicle.settings.node.relay has no description options.json> error: option programs.radicle.settings.node.scope has no description options.json> error: option programs.radicle.settings.node.workers has no description options.json> error: option programs.radicle.settings.preferredSeeds has no description options.json> error: option programs.radicle.settings.publicExplorer has no description options.json> error: option programs.radicle.settings.web has no description options.json> error: option programs.radicle.settings.web.pinned has no description options.json> error: option programs.radicle.settings.web.pinned.repositories has no description options.json> error: option programs.radicle.uri.rad.browser.preferredNode has no description options.json> error: option programs.radicle.uri.rad.vscode.extension has no description options.json> error: option services.radicle.httpd.args has no description options.json> error: option services.radicle.httpd.environment has no description options.json> error: option services.radicle.node.args has no description options.json> error: option services.radicle.node.environment has no description

[matthiasbeyer]

It also seems that nixpkgs needs to be refreshed:

error: radicle-cli cannot be found in pkgs

I don't know how this mechanic works in home-manager, so I cannot comment on that. But without radicle-cli, this PR is not possible :laughing:

[lorenzleutgeb]

@khaneliman, @matthiasbeyer thanks for your attention, but please don't waste your time reviewing this just yet. I know how to make my way through CI failures, and I will change the status of the PR from "Draft" to "Ready for review" when ... well, when it is ready for review.

In the meantime, feel free to push actual fixes like @matthiasbeyer did in https://github.com/nix-community/home-manager/pull/5409#issuecomment-3196993658, but posting errors that CI can catch is just noise to me, TBH.

Thanks for your understanding.

[lorenzleutgeb]

Opening this up for review. The simple test added passes. Happy to have your comments @matthiasbeyer, @khaneliman.

[lorenzleutgeb]

I believe I have resolved most issues pointed out by the reviewers, and the hardening was relaxed to not deny @timer, which according to man:systemd.exec(5) is about system calls for scheduling operations by time (man:alarm(2), man:timer_create(2), …), and I think that is acceptable.

[ju1m]

I believe I have resolved most issues pointed out by the reviewers, and the hardening was relaxed to not deny @timer, which according to man:systemd.exec(5) is about system calls for scheduling operations by time (man:alarm(2), man:timer_create(2), …), and I think that is acceptable.

Nice catch, we allowed @timer in NixOS too, because it is required by radicle-node during git upload-pack:

https://github.com/NixOS/nixpkgs/blob/7c05be024d9aaf7647204b8a456c74b03bd7d808/nixos/modules/services/misc/radicle.nix#L293-L296

[khaneliman]

In the end, I think the only thing that would be nice before a merge is the gitPackage package option and some tests to verify the module behaviors. The other things can be refactorings/features whenever someone is interested in tackling the support.

After typing that out, though... it does make me wonder if it would be worth introducing the concept of dependencies like we did in Nixvim so that each module doesn't need to declare it's own ancillary dependency package options...

[ju1m]

I've been using this PR for a month, is there any hard blocker to get this merged? Or is it only problems that can be solved later?

[khaneliman]

I've been using this PR for a month, is there any hard blocker to get this merged? Or is it only problems that can be solved later?

Looks like contributor stopped responding to proposed changes. We can merge, as-is, and add the desired changes in a follow up PR.

[lorenzleutgeb]

Hey @khaneliman! Yes, I did stop responding here, but only because I was busy with other things. No bad intentions or anything. I could've pinged here that it'd take me a while to follow up. Sorry that I did not. Thanks for the merge, and I hope that the remaining issues can be resolved soon.

[MordragT]

Hey sorry if this is obvious but I just tried to use this and I cannot really seem to get this to work. So when using programs.radicle it seems like the settings are not sufficient to directly use the cli, now I need to use rad auth which conflicts with the config.json symlink (read-only). Then I tried out services.radicle.node and set programs.radicle.enable to false, using rad auth to setup my profile. Now the systemd user service is telling me that the keystore is encrypted and a passphrase is required. Now I didn't test if setting no password for my profile works then with the radicle node service, but I feel like I might be missing something.

[lorenzleutgeb]

@MordragT if you:

1. want to share the same secret key for your user identity and your node ID (which is the standard way of doing it currently), and
2. you have set a passphrase for the secret key, and
3. you are using this module to start radicle-node

then, you will have to communicate your passphrase to radicle-node.

With Radicle 1.5, the current release, you have three options:

1. Set the environment variable RAD_PASSPHRASE of the radicle-node process to your passphrase. You can do this by using home-manager and setting the environment for the radicle-node service.
2. Remove the passphrase from the secret key (using OpenSSH tooling; your key is probably in ~/.radicle/keys/radicle). Just keep in mind that this means someone copying this file is copying your Radicle identity. (This removes precondition 2. above.)
3. Do not use the home-manager module for now and use rad node start instead, which will prompt you for the passphrase and then hand it to the radicle-node process. (This removes precondition 3. above.)

With Radicle 1.6 (which will likely be released within the next two weeks), you will have more options to resolve:

1. It will be possible to use systemd credentials. This is similar to suggestion 1. above for Radicle 1.5, but more secure.
2. It will be possible to use a different secret key for your user identity and for the node ID. I would not recommend doing this just yet though, as rad sync status does not perfectly handle this case yet. This is also why you won't find it announced in the release notes. (This removes precondition 1. above.)

[MordragT]

@lorenzleutgeb Ah thank you for the information. Then I will just use the cli for now and wait for 1.6 :+1:

[ju1m]

@MordragT beware that as far as I was able to test above, as of systemd v257.7, LoadCredentialEncrypted= is not supported in user services, it should be in systemd v258. You need it to keep your SSH key encrypted when radicle-node.service is not running.

To use it, you'll have to reencrypt your SSH key for each one of your hosts and users with:

cp ~/.radicle/keys/radicle{,.encrypted-backup} # In case you need to migrate to another computer
ssh-keygen -p -f ~/.radicle/keys/radicle
systemd-creds encrypt --user --uid=$USER --name xyz.radicle.node.secret ~/.radicle/keys/radicle ~/.radicle/keys/radicle.cred

Beware that by default systemd-creds --user uses /var/lib/systemd/credential.secret, /etc/machine-id, any TPM chip on the encrypting host, and the user's numeric UID and name.

I guess it would be more user friendly if radicle could just use something like ssh-agent (or gpg-connect-agent in SSH compatibility mode) to ask for the passphrase of the SSH key. With the activation socket enabled it would ask the passphrase at the right time.