To keep expectations similar to the seed command after the changes in
the companion patch:
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/patch/3be0e68b8948e65431a288f225454bafd93de34a
This introduces rate limits for the `ChannelReader` to limit DDoS attacks and
attempts to upload repositories that are larger than a node is will to permit.
The limiter sets the total number of bytes it is will to accept in a single
exchange, defaulting to 500MB. This means that initial fetches will prevent
large repositories, but is plenty for new packfile data to be sent in subsequent
fetch exchanges.
The limit can be configured within the node's config file, under the limits.
If an upload-pack is of a considerable size, the writer thread will be busy
writing bytes to the receiving side. During this period, the receiving side will
not be sending any bytes.
To ensure that the reader does not exit while the writing thread is performing
writes, the reading side will check when the last time a write was performed. If
it has not reached the timeout, then it can continue attempting to read.
Otherwise, it will break out of the loop; killing the upload-pack process safely.
Similarly to pushing using the `file://` protocol and `libgit2`, fetching will
be slow – so instead use `git fetch` directly to perform the `checkout`.
This gives the possibility to see the inventory of another node than self.
This does replicatee the functionality of 'rad node routing --nid', but
feels like a more intuitive command to try.
In issue #[2836] of `libgit2`, the speed of `libgit2`'s `file://` protocol for
git operations is found to be very slow. This is further corrobarated by `rad
init` taking 13 hours to initialise the hardenedbsd [ports] repository.
There are two areas where the `heartwood` project uses `libgit2` to push using
the file protocol. The first is when via the `trasnport::local` smart transport
registration and the second is the final push to storage in the `git-remote-rad`
binary.
When both these `push` operations are changed to use the `git` binary instead,
the [ports] repository can be initialised in less than 10 minutes (nearly 100x
speed up).
This change is clearly required if `heartwood` wishes to support larger
repositories.
[2836]: https://github.com/libgit2/libgit2/issues/2836
[ports]: https://git.hardenedbsd.org/hardenedbsd/ports
Update the rust toolchain version to 1.85.
Note that this is not the latest, however, it is the latest available in nixpgs,
so this version is good enough for now.
This resolves issues:
- 111cf90 (`handler` is not async-signal-safe)
- c8e0300 (`libc::signal` should not be used)
- b91c6c3 (Mutex can cause signals to be missed)
See also: patch 8e05702.
The API of `radicle-signals` is the same as before, and so uses of it
don't need to be and aren't changed. The behavior is slightly different
in that:
- If the channel is full then signals will not be lost, which is an
improvement. This is achieved without blocking in the signal handler.
This is possible because of the counters approach along with the
internal receipts-processing thread of the `signals_receipts` crate.
- `install()` and `uninstall()` might block very briefly if necessary to
acquire the mutex, which is now internal to and managed by the
`signals_receipts` crate, only if there are concurrent calls to them
(which is unlikely), but such blocking is guaranteed to be bounded to
be very brief. This is done so they no longer can fail to do their
purpose, which is an improvement. They still return errors if the
handling is already installed or uninstalled, respectively, which
preserves the previous use cases.
- The new `finish()` function is introduced. This is provided in case
it's ever needed to completely clean-up the facility, by terminating
the internal receipts-processing thread, to be like it hadn't been
installed before.
- The user must ensure that the notifications channel is disconnected,
by dropping the receiver(s), when doing `uninstall()` or `finish()`.
Such dropping usually occurs naturally, and already occurs for all the
preexisting uses of `radicle_signals`. (The `signals_receipts` crate
is capable of a more robust approach, but this commit doesn't use
that, to avoid changing the preexisting uses of `radicle_signals`.)
- The `TryFrom` impl for `Signal` is of `SignalNumber` which is `c_int`,
instead of `i32`, because `c_int` (the type of signal numbers) might
not be `i32` on all platforms (POSIX only requires `c_int` to be at
least 32-bit).
The version of `radicle_signals` is incremented, to reflect those
changes and the substantially different internal implementation.
The new dependency on the `base64` crate is needed by the
`signals_receipts` crate for it to work on macOS, because its dependency
on the `sem_safe` crate uses `base64` as part of creating anonymous
semaphores on macOS (which lacks support for unnamed semaphores (in
violation of POSIX)).
Signed-off-by: Derick Eddington <kcired@pm.me>
Signed-off-by: Lorenz Leutgeb <lorenz@leutgeb.xyz>
The help shows that `--emoji` is optional, however it was not.
Instead of making `--emoji` mandatory, I added an emoji picker
for the emojis featured in the web ui.
`--emoji` is now (really) optional, but can be used to react
with other emojis not included in the selector or the web ui.
We don't have network access under Ambient, so we need to run "cargo
install" with the "--offline" option to prevent it from trying to
check current available versions of crates.
Signed-off-by: Lars Wirzenius <liw@liw.fi>
In the 'clone' command, a 'signer' is instanciated just to get the
public key. In the 'job' command, a 'signer' is instanciated early,
even when the subcommand doesn't use it.
That's unnecessary, and infers the potential use of RAD_PASSPHRASE.
In those cases, avoid instanciating a 'signer'.
Version 0.5.13 was yanked, resulting in the following warning when
building with --locked:
warning: package `crossbeam-channel v0.5.13` in Cargo.lock is yanked
in registry `crates-io`, consider running without --locked
Adds an `Op::load` helper method for loading an `Entry`, given its `Oid` and the
`store` it is stored in.
This can be useful for downstream consumers to inspect operations on COBs given
a single `Oid`, without having to load the entire object and/or graph.
It can also be useful when looking at implementing COB stream primitives.
Instead of collecting the results and returning the collection as an
iterator, introduce `FollowPolicies` and `SeedPolicies` types, which
implement `Iterator`.
Note that a call in `service` changed due to the lifetime borrow. It
simply `collect`s into a `Vec` for the time being.
Provide functionality to lookup the `NodeId`s associated with a given
`Alias`.
The use for this functionality is to allow callers to use aliases as
shorthands for `NodeId`s, but still refer to the exact identifier.
The implementation allows for searching using the `LIKE '%<pattern>%'`
queries in sqlite, so searches do not have to be exact matches.
The use of `Transaction` outside of the `radicle` crate requires that a newtype is used, if the upstream code wants to write methods, such as:
```
pub struct Transaction<R>(store::Transaction<MyCob, R>);
impl Transaction<R> {
pub fn add_foo(&mut self, foo: Foo) -> Result<(), store::Error> { /* code */ }
pub fn add_bar(&mut self, bar: Bar) -> Result<(), store::Error> { /* code */ }}
```
This works up until the point that it tries to re-use the
`Transaction::initial` method.
To make this possible, the method needs to know that it can be
converted to the upstream `Transaction` and back to `radicle`
`Transaction`.
The nix flake's checks were failing for various reasons. The following fixes are
applied to get it up to date again.
- Update to release-24.11, since `crane` requires it – also to keep up-to-date
- Add `.json` to the source filters to allow for testing patch migration
- Ensure that the `rad` and `git-remote-rad` binaries are built for the nextest
check. N.b. the binaries need to be in the target dir of `radicle-cli` since
that is where the nextest check runs from.
- Add `cargo-audit` and `cargo-deny`, to the devShell, to allow for running those
tools locally
- Bump `gix-path` to 0.10.11 to avoid a vulnerability[^0]
[^0]: https://rustsec.org/advisories/RUSTSEC-2024-0371
Extend the ranges of emojis that are supported, listed
[below](#new-emojis-supported).
To ensure that single `char` emojis are supported, the `emojis` crate
is added as a dev dependency, using it to check that a `Reaction` can
be constructed for the two groups `SmileysAndEmotion` and
`PeopleAndBody`.
### New Emojis Supported
'🩵' 0x1FA75
'🩶' 0x1FA76
'🩷' 0x1FA77
'🫀' 0x1FAC0
'🫁' 0x1FAC1
'🫂' 0x1FAC2
'🫃' 0x1FAC3
'🫄' 0x1FAC4
'🫅' 0x1FAC5
'' 0x1FAC6
'🫠' 0x1FAE0
'🫡' 0x1FAE1
'🫢' 0x1FAE2
'🫣' 0x1FAE3
'🫤' 0x1FAE4
'🫥' 0x1FAE5
'🫦' 0x1FAE6
'🫨' 0x1FAE8
'' 0x1FAE9
'🫰' 0x1FAF0
'🫱' 0x1FAF1
'🫲' 0x1FAF2
'🫳' 0x1FAF3
'🫴' 0x1FAF4
'🫵' 0x1FAF5
'🫶' 0x1FAF6
'🫷' 0x1FAF7
'🫸' 0x1FAF8
The `parse_ref` and `parse_ref_namespaced` documentation used 4 space
indentation for the reference names. Unfortunately, `cargo test` attempts to
interpret this as code.
Use triple-backtick code fencing, with `text` and `no_run`, instead.
Add the remaining `Patch` actions to the CLI interface. These include:
- React to a revision
- Edit a comment
- React to a comment
- Redact a comment
The `react` subcommand is added in a straight-forward manner.
The comment commands are slightly less straight-forward. In order to
keep to one layer of subcommands, these variants are done through the
`rad patch comment` subcommand. They are accessed via options:
`--edit`, `--react`, and `--redact`, respectively. Each of these
options takes the `CommentId` for which the action is affecting. The
`message`, `react` (introduced for `rad patch react`), and `undo`
variables repurposed for this subset of actions.
Change configuration of native CI to only deny warnings from the
compiler, but no all clippy lints.
Previously we ran "cargo clippy --all-targets --workspace -- --deny
clippy::all", which overrides the allows for specific clippy lints in
the source code. We don't want that.
Signed-off-by: Lars Wirzenius <liw@liw.fi>
Indicate that the `rad issue state` operation was successful to the
user by printing a message to the console.
Solves:
rad issue show 71020de8478b15b3f7a619f2f93d3cfb8771cde2
Add the ability to edit an issue comment to the `rad issue` command.
This is achieved by adding an `--edit` option to `rad issue
comment`. Note that if `--reply-to` and `--edit` are both specified,
then this results in an error.
To be able to query the `BTreeSet` that shows which comments are
resolved by a specific revision and the `Iterator` of `Label` we require
some methods to obtain them.
Provide better documentation for the two methods.
Solves the issue:
```
rad issue show 4603f55d97a0776f37bae2f9d2ba7d455d8a4c83
```
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
rlimit values have different types on Linux and FreeBSD, as well as
64-bit and 32-bit platforms, so stick to the type rlim_t provided by the
libc crate.
Lorenz Leutgeb
Sekhat Temporus
Fintan Halpenny
Lars Wirzenius
Richard Levitte
Sebastian Thiel
Derick Eddington
tippfehlr
Ivan Stanković
Yorgos Saslis
Sebastian Martinez
Leah Neukirchen