| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
Review 2, N12: a strict remake kept only the values at the signed
places its manifest names, and copied what holds them as it was. A
member that replaced _continuum/users by a scalar before the turn left
the strict epoch without a registry, where any member may do anything.
The holders of the registry, `_continuum/access` and the bans are now
made anew as maps, with only what the manifest keeps copied into them;
and a manifest keeping no user is refused (at proposal, vote and build
alike), as a strict swarm without one would trust every member.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
This allows a lot of operations to drop mut.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Instead of fixing base heads at when proposed, compact fixes them when
committing. This shrinks the window where writes can be lost if their
author restarts to the switch delay; during replace and import remakes
writes can still be lost during the voting period.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
POST /admin/remakes accepts specs with replace kind, e.g.:
{ "kind": "replace",
"baseHeads": ["..."],
"spec": {
"document": { "accounts": { ... } },
"rules": [
{ "from": "users", "to": "accounts" },
{ "from": "users/admin", "drop": true },
{ "from": "", "to": "" }
] } }
|
| |
|