Private-repo LFS operations need a signer capable of ECDH, which ssh-agent (the normal day-to-day flow after `rad auth`) can't provide -- that's a hard protocol limitation (standard ssh-agent only implements signing, there's no key-agreement request type), not a gap in our code, so there's no way to make it work "through the agent" the way signing does. Previously the only alternative to an unencrypted keystore was setting RAD_PASSPHRASE, which breaks the normal ssh-agent-based workflow and means putting a password in an environment variable -- not ergonomic, and not how any other `rad` command behaves. `rad` already has an established fallback for exactly this situation: `crate::terminal::io::signer` tries ssh-agent first, and if that's unavailable/unregistered and we're connected to a TTY, prompts interactively for the passphrase via `inquire` (reusing the existing `PassphraseValidator`). `lfs_crypto::load_signer` was missing this last step entirely -- it only tried "unencrypted keystore" then "RAD_PASSPHRASE" then gave up. Added the same interactive-prompt fallback, reusing the exact same validator/prompt helpers already used elsewhere, before falling back to a hard failure. This covers the common case (an interactive `git commit` triggering the pre-commit hook, which inherits the terminal's TTY) with no environment variable needed at all. Only genuinely non-interactive contexts (CI, a script with no TTY) still need RAD_PASSPHRASE -- and get a fast, clear failure rather than hanging, since `inquire` returns `Ok(None)` on `NotTTY` rather than blocking (verified: piping /dev/null as stdin still fails immediately, not a timeout). Verified against a real encrypted keystore through an actual pty (via `script`, since a plain non-interactive shell doesn't have a TTY to prompt on): the masked "Passphrase:" prompt appears, accepts the typed passphrase, and produces a correctly encrypted note -- with RAD_PASSPHRASE unset the entire time. |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .radicle | ||
| build | ||
| crates | ||
| debian | ||
| radicle-lfs-transfer@d67ac79f40 | ||
| scripts | ||
| simulation | ||
| systemd | ||
| windows | ||
| .codespellrc | ||
| .dockerignore | ||
| .env.seed | ||
| .envrc.sample | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .gitmodules | ||
| .gitsigners | ||
| .rustfmt.toml | ||
| .typos.toml | ||
| ARCHITECTURE.md | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| Cargo.lock | ||
| Cargo.toml | ||
| DCO | ||
| HACKING.md | ||
| LFS-IPFS.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| NOTES-lfs-notes-fetch-bug.md | ||
| README.md | ||
| RELEASE.md | ||
| VERSIONING.md | ||
| build.rs | ||
| clippy.toml | ||
| deny.toml | ||
| flake.lock | ||
| flake.nix | ||
| git-remote-rad.1.adoc | ||
| justfile | ||
| rad-id.1.adoc | ||
| rad-patch.1.adoc | ||
| rad.1.adoc | ||
| radicle-node.1.adoc | ||
| rust-toolchain.toml | ||
README.md
❤️🪵
Fork: Git LFS support, backed by IPFS
This is a fork of upstream
radicle-dev/heartwoodadding Git LFS (large file) support, with large file content stored on each contributor's own local IPFS node rather than a central server. Everything below the horizontal rule is upstream's own README, unchanged. SeeLFS-IPFS.mdfor the full design, troubleshooting, and background — this section is just the quick start.The LFS byte-transfer logic lives in a separate, small companion repository: radicle-lfs-transfer, included here as a git submodule.
Dependencies (Arch Linux)
# To build and install rad/radicle-node/radicle-lfs-transfer sudo pacman -S --needed rust git openssh base-devel # To actually use Git LFS (not needed to build/install anything) sudo pacman -S --needed git-lfs kuboOn other distributions: a Rust toolchain (e.g. via rustup), Git, OpenSSH, a C toolchain — and, only for using
rad lfs, Git LFS and Kubo.Zero to usable
# Clone with the submodule git clone --branch rad-lfs-ipfs --recurse-submodules \ ssh://git@git.hswro.org:9022/mab122/radicle-heartwood-lfs.git cd radicle-heartwood-lfs # Build & install rad, radicle-node, git-remote-rad, and rad-lfs-transfer to one place cargo install --path crates/radicle-cli --force --locked --root ~/.radicle cargo install --path crates/radicle-node --force --locked --root ~/.radicle cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle cargo install --path radicle-lfs-transfer --force --locked --root ~/.radicle # Add the install root to your PATH (e.g. in ~/.bashrc / ~/.zshrc) export PATH="$HOME/.radicle/bin:$PATH" # Verify rad --versionFrom here, use
radexactly as upstream describes below (rad auth,rad init, etc). The only new commands arerad lfs init(run once per repository you want large-file support in) andrad lfs rekey(run after granting a new collaborator access to a private repository, so they can decrypt previously-committed LFS objects too) — seeLFS-IPFS.mdfor that workflow and how private-repo content gets encrypted before it reaches IPFS. Nothing above requires IPFS; Git LFS support specifically needs a runningipfs daemon, andrad lfs initwill tell you plainly if one isn't reachable rather than failing confusingly later.
Radicle Heartwood Protocol & Stack
Heartwood is the third iteration of the Radicle Protocol, a powerful
peer-to-peer code collaboration and publishing stack. The repository contains a
full implementation of Heartwood, complete with a user-friendly command-line
interface (rad) and network daemon (radicle-node).
Radicle was designed to be a secure, decentralized and powerful alternative to code forges such as GitHub and GitLab that preserves user sovereignty and freedom.
See the Radicle home page for general information, and the Zulip chat to talk to the project.
See the Protocol Guide for an in-depth description of how Radicle works.
Installation
Requirements
- Linux or Unix based operating system.
- Git 2.34 or later
- OpenSSH 9.1 or later with
ssh-agent
📀 From binaries
Requires
curlandtar.
Run the following command to install the latest binary release:
curl -sSf https://radicle.dev/install | sh
Or visit our download page.
📦 From source
Requires the Rust toolchain.
You can install the Radicle stack from source, by running the following commands from inside this repository:
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
Or directly from our seed node:
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
Running
Systemd unit files are provided for the node under the /systemd folder.
They can be used as a starting point for further customization.
For running in debug mode, see HACKING.md.
Feedback
If you have feedback, feel free to create issues using rad issue, join
our Zulip, or email feedback@radicle.dev.
Emails sent to this address are automatically posted to
our public #feedback channel on Zulip, revealing the
From header (which usually contains your name and email
address). This allows us to discuss your feedback on Zulip, and, if necessary,
respond to you via email.
Contributing
See CONTRIBUTING.md and HACKING.md for an introduction to contributing to Radicle.
License
Radicle is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.