| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N4: replay_newest names the node the document's author once,
before its first group. Taking a refused group back forks the document
at the heads before it, and Automerge's fork has no author; when the
refused group was the actor's first change, the next one was committed
as seq 1 without the footer naming the node, refused as "it names no
node", taken back too, and so on: the whole replay in the quarantine
with a misleading reason.
The fork now names the node its author again. Test: the first group
refused (a capability revoked in the new epoch), the next replayed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A strict remake takes a majority of members whose --strict-keys take
its manifest's signer: no node votes for one without, so
--follow-strict-remakes (1173) goes. A node that doesn't vote still
switches once the others commit, as with any remake.
So that an operator can tell why one fails: a strict remake aborted
for want of a majority (the voting period over, or a majority out of
reach) says in its reason (GET /admin/remakes/{id}, and the
coordinator's log) which members didn't vote, and that a member votes
for one only with its manifest signed by a key of its --strict-keys.
Each of those logs why itself (`Not voting for a strict remake`).
The sim a_strict_remake_too_few_take: only a takes the manifest; the
remake aborts, naming b and c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until a swarm is strict, the user a change names is its node's word, so
any member could have planted registry entries, policy, bans or
user-signed values as any user, plain or signed by a key it put there
itself; writing the strict policy trusted all of it as it was.
A remake of a new kind, `strict`, turns a swarm strict instead:
* Its content is a manifest (access::strict): the swarm, the strict
policy, and each value kept at the places values are signed, by the
SHA-256 of its JSON, signed by an operator (ssh-keygen -Y sign -n
continuum-strict).
* Every node builds the next epoch as compaction does, keeping at the
signed places only the values the manifest names, as they were at
the base, and writing its policy (RemakeKind::protocol, the one kind
that changes protocol data). Writes after the base reach the new
epoch only by replays, judged by the strict policy.
* A node votes for one only with its manifest signed by one of
--strict-keys, keys given out of the document; without any, for none
(logged once, `Not voting for a strict remake`), unless
--follow-strict-remakes. A coordinator proposes only what it would
vote for (403). Once a majority commits one, every node switches, as
with any remake: refusing to switch would only cut a node off.
* GET /admin/strict-manifest gives the manifest keeping everything held
now, the values for review and the heads they are at;
continuum-signed strict shows them, signs once confirmed and proposes
at those heads.
The sim a_swarm_turning_strict_through_a_remake: a member plants a
registry entry as a manager; the operator's manifest leaves it out; a
and b, given the key, commit; c, without, follows; the entry is gone
and the policy strict everywhere.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Review finding 7, second part: a record carried into a new epoch whole
(proposal and decision in one change) was taken from any member, for
any remake ID. A member could write a forged record, decision included,
for a fresh ID in a single change.
The snapshot's epoch metadata now names the remake's coordinator, as
the quorum built it. The carried-record exception holds only in a
later epoch, only for the remake that made it, and only from the
coordinator its snapshot names, where there is no record yet. Wire
version 43: the snapshot, and so the epoch ID, changes.
The review suggested carrying the record inside the snapshot instead.
The snapshot can't hold the decision, which names the snapshot's own
hash. So the snapshot vouches for who may carry the record instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A switching or rejoining node replays late writes as fresh changes
naming each write's user, and nothing judged them before they left: a
replay every node would refuse (a revoked capability, a second
envelope at a signed path, readers changed) was refused everywhere,
and with it everything the node wrote after it.
Under a policy, replay_newest now judges each group it commits as
every node will (rules::judge_held, in the new epoch); one they would
refuse is taken back (forked at the heads before it, same actor) and
its paths quarantined with the reason. replay_newest takes the epoch.
Review finding 3 (remake replays).
|
| |
|
|
|
|
|
|
|
|
| |
POST /admin/quarantine/{id}/replay needs write on _continuum, which
never covers user data, and replayed every path of the entry as the
user who asked: every node refused the user data in it. It now
replays only the paths the user may write and keeps the rest in the
entry (left), for one who may; 403 if the user may write none.
Review finding 3 (quarantine replays).
|
| |
|
|
|
|
|
|
|
| |
A node refusing changes a peer brought tells it which broke a rule; the
peer judges them itself, and if its rules refuse them too, drops them
with all built on them (its document forked without them, a fresh
actor), quarantining its own writes among them. Wire version 42.
Auth plan M6 (rejoin on taint).
|
| |
|
|
|
|
|
|
| |
A remake's replay writes each value as the user who wrote it,
splitting where several users wrote under a path, so replays are
judged as the original writes.
Auth plan M6 (remakes, 2.4).
|
| |
|
|
|
|
|
| |
Forget records and released quarantines name the user who made them,
so they are judged by its capabilities.
Auth plan M6.
|
| |
|
|
|
|
|
|
| |
registry::exists counted any value at _continuum/users as a registry;
keys_at answers None where there is no map, and its users (records,
members, forget records, remakes) say what they make of it.
Auth plan M1 (fix).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This gives bench_replay a speedup of ~8x/64x/280x.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This ensures that stale reads show every write that was answered.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This allows a lot of operations to drop mut.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
