We ensure that a `rad/root` ref is included in the signed refs file
under `rad/sigrefs` for all remotes. This prevents a certain kind of
"grafting" attack where signed refs can be copied between repositories,
by having the peer sign over the identity root together with the data refs.
When verifying signed refs, we ensure that the ref is present and points
to an identity branch root that matches the repository identity containing
the signed refs.
Alternatives: lots of alternatives were considered, but this one doesn't
introduce any changes to the signing. The `rad/id/root` name was
considered but is invalid due to `rad/id`.
Add a fetch refspec to fetch tags from a Radicle remote. The
`--no-tag` option is also included. This is to ensure that it is easy
to collaborate by having tags placed in the remote namespace of
another peer. However, if the namespace is the default `rad` remote,
then tags are expected to be allowed -- this is to pave way for the
feature of canonical tags.
In the tests, the `--tags` option is removed -- and is generally
recommended that it is not used. This is to ensure that it does not
override the `--no-tag` option.
To facilitate edit actions, take URIs instead of the actual blobs. This
means API callers don't have to load all the blobs just for them to be
re-hashed when an edit action is submitted.
There are some peculiarities when dealing with the `Identity` COB since
the embed is the identity document itself. We handle that special case.
Due to the way review editing was implemented, we were losing comments
on previous review edits.
Here, we add a new `review.edit` action that is specifically for
editing, and make the existing `review` action fail silently (for
backwards compatibility) in case it is used when there is already a
review.
We also simplify the review data structure by only keeping track of one
review per author per revision, instead of all edits. Later, if needed,
it will be possible to keep track of all review edits.
When creating a new upstream for the patch workflow, the remote name is always
assumed to be `rad`.
It's possible for users to use another remote name but still use a `rad://` URL
for pushing. To allow for this, the function that creates the upstream entry now
takes a remote name. In the remote helper, `rad patch checkout`, and `rad patch
set` the remote can be optionally specified and fall back to the `rad` remote
name as a default.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
When two `review` actions were posted by the same author, for the same
revision, an error was returned, cancelling evaluation for that author.
This caused certain patches to for eg. lose their merge status.
To remedy this, we *allow* multiple `review` actions per revision, but
simply take the last one as the "current" review. Since this makes the
`review.edit` action redundant, we remove that action completely. This
is safe, as none of the tools created review edits.
In case of a bug or failed cache update, there may be objects in the
cache that are no longer in storage.
When doing a full re-cache, remove all existing entries from the repo
first.
Add the `rad unblock` command for reversing the effect of blocking an NID or RID.
In both cases, the entry is removed from the DB, if the policy was set to block
-- otherwise it is a no-op.
This adds an option to `rad init` to initialize a working copy with
an existing radicle repository in storage:
rad init --existing <rid>
This sets up the remote(s) and configures the repo for you.
The patch creation flow would be partially interrupted when creating a
patch via a detached HEAD state. The creation of an upstream branch
would fail since there is no branch to set an upstream for. It would
result in the following error:
✓ Patch 6035d2f582afbe01ff23ea87528ae523d76875b6 opened
To rad://z42hL2jL4XNk6K8oHQaSWfMgCL7ji/z6MknSLrJoTcukLrE435hVNQT4JUhbvWLX4kUzqkEStBU8Vi
! [remote rejected] HEAD -> refs/patches (git: reference 'HEAD' is neither a local nor a remote branch.; class=Invalid (3))
error: failed to push some refs to 'rad://z42hL2jL4XNk6K8oHQaSWfMgCL7ji/z6MknSLrJoTcukLrE435hVNQT4JUhbvWLX4kUzqkEStBU8Vi'
To fix this, the reference that's resolved is checked to see if it a
local branch. If not, it will return early.
The behaviour is tested in the `rad-patch-detached-head` example.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
- Remove the `name` field as it is not required in the new design.
- Rename `imageUrl` to `bannerUrl` to hint users that it's going to be
used as a header image.
- Add a new field `avatarUrl` so node operators can customize their
node further.
Remove the old `quorum` function in favour of using the newly introduced
`Canonical` code. Port over the tests to use the `Canonical` type. The change is
minimised by introducing a helper function called `quorum` in the test module
that acts like the old function.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Introduces a type, `Canonical`, to make manipulating and calculating canonical
reference quorum's easier.
The idea is that the type can be constructed by providing a set of delegates and
the reference name for which the calculations are referencing. It can construct
the set of tips and can output the quourum.
It provides a shortcut for constructing the `default_branch` set of tips.
It also provides some extra methods for helping in quorum calculations that will
be used within the remote helper code.
Note that this does not yet replace the `quorum` function in the `git` module --
this is to help minimise the review of this commit.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
When calculating a quorum there was a case where two heads that were equal would
result in double-counting, allowing the quorum to pass a threshold higher than
the expected votes.
To prevent this, each head is immediately counted as a direct vote. Then, when
comparing the head to the rest of the set, if they are equal that iteration
would be skipped. This is because the merge base of two equal commits is that
commit, resulting in the double-counting.
Note that the `skip` can also skip the current head, so `i + 1` is used.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
1. Adds a user-agent string to the node announcement. This lets us keep
track of what software version everyone is running. Especially useful
to see what percentage of the network has upgraded to a new release.
For old nodes, this defaults to the string `/radicle/`.
The user agent format is roughly based on BIP 0014.
2. Advertize protocol version in node announcement.
By advertizing the protocol version, nodes can decide to only connect to
peers with a compatible version. The default and current version is `1`.
We bundle these two changes as they both modify the node announcement
and node database.
3. Swap the order of the fields in announcements to make the message
extensible.
This prevents potential memory leaks. We also ensure that sends fail
instead of blocking, in case the channels are full.
Additionally, we add some metrics to report on channel size.
Previously, our advertized inventory was not always correct: when we
stopped seeding a repository, it was still advertised as part of our
inventory until node restart, because the `Storage` type doesn't have
access to seeding policies.
In this change, we remove the concept of inventory from `Storage` and
make the authoritative place for it the routing table in our database.
To make this work, we have to add our node to the database on profile
creation, to not violate the foreign key constraint on the routing
table. Hence, the tests are changed to include our alias which is now
always available.
This is a change to the `config.json` file which removes certain options
that are best not touched and changes some options to make them easier
to work with.
1. We change the default journaling mode to "wal" and remove the config
option.
2. We remove the option to set the peer connection "target", as it's not
a good idea to set this to a different value, as it affects the
network.
3. We combine seeding policy & scope, since there's no need to set the
scope when the policy is "block". In that case, we always want to
block "all" remotes. The new policy configuration has the following
schema:
{ seedingPolicy: { default: "block" | "allow", scope?: "all" | "followed" } }
The "scope" key is not used when "default" is set to "block".
4. We add an `extra` field to the node config for options that are not
recognized. We use this to warn the user.
We use the *staggered broadcast* technique when relaying gossip messages
to reduce message amplification. In our basic simulation, it brings
amplification down from 3.5 to 1.5.
The idea is simply to accumulate gossip messages and relay them after a fixed
interval of time. This has two effects:
1) Old messages that haven't been sent yet are replaced by newer ones,
so only one message is sent after the delay.
2) Because nodes have their own intervals, messages are not all sent at
the same time, which reduces the chance of messages crossing paths.
For now we only turn this on for inventory messages, since this is the
least likely to be noticed by users, and also the most problematic
currently.
cloudhead
Fintan Halpenny
Alexis Sellier
Lorenz Leutgeb
Sebastian Martinez
Rūdolfs Ošiņš