Lorenz LeutgebandFintan Halpenny
df6524e7e2
Reasons for the rewrite:
- Migrate away from `ec25519` as our implementation of Ed25519,
because that crate is unmaintained.
Instead of `ec25519` we use `ed25519-dalek` which is the most popular
implementation of Ed25519 in Rust.
- Migrate away from `amplify`, because we make very little use of its
features. Here, we only use `amplify::Bytes32`, which is just a thin
wrapper of `[u8; 32]`.
Instead of `amplify::Bytes32` we use `type PublicKeyBytes = [u8; 32]`.
The realization that `ExtendedSignature` is not really tied to SSH, but
is merely a representation of a key together with a signature, allows to
relax the bounds on traits in `radicle-cob`.
Separating out uses of "public key" (a rather simple model of a key,
just 32 bytes) and "verifying key" (an actual point on the Edwards
curve, ready to verify signatures, using more memory than just 32 bytes)
allows a more sensible definition of `crypto::Signer`, which propagates
to `radicle-cob`, `radicle`, `radicle-cli`, `radicle-node` and
simplifies trait bounds.
In `radicle-node`, make the fact clearer that actually the secret key
itself is required (for our implementation of Diffie-Hellman) not
"just" signing. This results in removal of the generic argument
(usually called `G`) of multiple types.
Concretizing the types in `radicle-node` this way, i.e. by (morally)
setting `G = radicle_crypto::SigningKey`, leads to removal of
`MemorySigner` and `MockSigner`, as they really just wrap a signing
key.
Re-exporting `ed25519::Signature` (via re-export in `ed25519-dalek`)
is hopefully more future-proof than using our own type for signatures.
However, the fact that `ed25519::Signature` is not serializable and
does not implement `std::hash::Hash` means that we have to resort to
ad-hoc solutions in `radicle`:
1. The Identity COB requires serialization of signatures. These are
generally questionable, since the security of the Identity COB
should rely on the security of Signed References. In the medium
term we might even want to consider ignoring signatures in actions.
2. When reading Signed References, detection of Replay Attacks uses
a `HashMap` keyed by signatures. This detection only exists for
backwards compatibility.
These two use cases are exotic enough to warrant ad-hoc implementations.
By not wrapping `ed25519::Signature`, we encourage writing more widely
compatible code in the future.
Co-authored-by: Fintan Halpenny <fintan.halpenny@gmail.com>
❤️🪵
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.