This is conditional on the target operating system being FreeBSDs.
HardenedBSD is FreeBSD but with changes. We determine which one it is,
by running 'sysctl --values hardening.version'.
Co-authored-by: Shawn Webb <shawn.webb@hardenedbsd.org>
The tests `rad-warn-ipv6.md` and `rad-warn-old-nodes.md` are meant to
primarily test the output of warnings. They test the output twice, via
`rad debug` and via `rad node status`.
Testing the output via one command should be sufficient.
When `Service::handle_message` handles `Message::Subscribe`, constraints
regarding visibility of repositories are not considered, this leads to
leaking RIDs of private repositories.
Add a corresponding check.
Add a test to verify that reference announcements relayed via subscribe
correctly apply visibility filtering, there by ensuring references of
private repositories are only propagated to nodes on the allow list.
The test regarding deduplication needs a fix: Ensure that all mock
repositories are public and in storage so that they do not
get filtered out in case of unknown visiblity.
Co-authored-by: Lorenz Leutgeb <lorenz.leutgeb@radicle.dev>
The examples do not import everything necessary to compile, so the doctests will
fail using `no_run`.
Instead, use `ignore` instead so that it does not attempt to compile the examples.
Similar to `rad [issue|patch] cache`, this will re-compute cached state
about the identity document. The identity COB does not cache to SQLite,
but there is `refs/rad/id`, which can become stale.
This is the result of
cp -r \
../radicle-git/radicle-git-ext/git-ref-format/core/src/{{cbor,check,deriv,lit,name,refspec,serde}.rs,{name,refspec}} \
crates/radicle-git-ref-format/src/
with the radicle-git workspace at commit
8c5df5ecbd3f2507d323608b52e1fbf7b177d864.
Refactor the `radicle-surf` crate to use OIDs from `radicle-oid` instead
of `radicle-git-ext`, and `radicle-git-ref-format` instead of re-exports
from `radicle-git-ext`. Also remove the dependency `radicle-std-ext`.
This requires changing `use`s, and an ad-hoc reimplementation of
`ResultExt::or_matches`.
The remaining changes (excl. tests) are automatic via `rustfmt` and
`cargo clippy`.
For testing, implement reconstruction of
https://github.com/radicle-dev/git-platinum
in particular of the commits
- a0dd9122d33dff2a35f564d564db127152c88e02
- 27acd68c7504755aa11023300890bb85bbd69d45
- e972683fe8136bf8a5cb2378cf50303554008049
and some tags.
`…/src/test/roundtrip.rs` was copied from the `test-helpers` crate in
the radicle-git workspace.
`…/src/test/{repository.rs,gen*}` was copied from the `radicle-git-ext`
crate in the radicle-git workspace.
In the radicle-git workspace, crates brought their own testing crates
along with them, usually in a subdirectory named "t". In the heartwood
workspace we use tests within the same crate.
This commit only moves files, so that it is easier to follow changes to
them in the upcoming commit.
This is the result of a simple
cp -r ../radicle-git/radicle-surf/ crates
rm -r crates/radicle-surf/{data,scripts,build.rs}
with the radicle-git workspace at commit
8c5df5ecbd3f2507d323608b52e1fbf7b177d864.
In `/Cargo.toml` and all `/crates/*/Cargo.toml`, remove homepage package
metadata. This field is inteded to carry the *homepage of the crate*. In
our case, no crate has an actual homepage on its own.
In all `/crates/*/Cargo.toml`, split package metadata into two or three
blocks:
1. name, version, and description (in this order)
2. Further metadata defined per crate.
3. References to the workspace.
Lines in blocks (2.) and (3.) are sorted lexicographically, and blocks
are separated by empty lines.
In `radicle-cli`, which is a binary crate (!) a few `pub use`s can be
removed. This forces `radicle-remote-helper` to depend on the library
crate `radicle-term` to access some of the types that were re-exported
from `radicle-cli`, making the dependency more obvious, and minimizing
the public symbols on `radicle-cli`.
The dependency on `radicle-cli` cannot be removed from
`radicle-remote-helper` easily, so is kept.
Running `cargo semver-checks` errors with
error: unsupported rustdoc format v57 for file:
…/heartwood/target/semver-checks/local-radicle-…/target/doc/radicle.json
(supported formats are v53, v55, v56)
Support for rustdoc format v57 is part of cargo-semver-checks 0.46,
which is not part of NixOS 25.11, which has reached EOL.
Re-point the "nixpkgs-stable" input to NixOS 26.05 to reach a newer
cargo-semver-checks and a NixOS version that is supported.
Update the flake.
In `df6524e7e21027c4eb128dd2eaab0a6d70a6d76d`, default features for
`zeroize` were disabled for the workspace in `/Cargo.toml`, accidentally
affecting `radicle-term`, since `radicle-term` depends on
`impl Zeroize for String` which is available on feature "alloc" only.
The Rust version used for development is tracked in
`/rust-toolchain.toml`, and the value specified there is used to set
`RUST_VERSION` in the `build/build` script. Thus, when using
`build/build`, the default value is unimportant.
However, ensuring that the default value remains consistent with
`/rust-toolchain.toml` is a maintenance burden.
Remove the default value. This increases friction of building without
`build/build`, but makes maintenance easier.
The re-exports from other crates got quite confusing.
Remove all `pub use` from `radicle-node`, and rewrite all `use`s
accordingly.
The result is a slight increase in the number of `use` lines, but with
improved clarity on which type is actually imported.
It appears that `radicle_node::PROTOCOL_VERSION` (which is a re-export
of `radicle::node::PROTOCOL_VERSION` is the only symbol exported from
`radicle-node` that is used in `radicle-cli` (except tests).
Since `radicle-cli` depends on `radicle` anyway, it is questionable how
much sense that re-export and use from a binary crate (!) makes.
Remove the re-export.
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>
Lorenz Leutgeb