carlos / platform Public

#162: sort order is not authority — a contested host vouches for nothing

adf29ebd's fifth rail said the home must be the FIRST-SORTING claimant of
its host. A second adversarial verification broke it twice, in the same
afternoon, and both breaks are the same mistake: a bucket listing is
lexicographic, so "first" is a property an attacker chooses, not a property
the platform grants.

  1. An attacker whose account prefix sorts BEFORE the victim's IS the
     owner under that rail. Their shadow of the victim's host vouched for
     their own replica, it passed all five rails, and the victim's public
     host was aliased to the attacker's process on that box — the original
     P1, intact. The test that shipped with the rail covered only the
     later-sorting half, and guarded its own fixture with
     `if mallory <= sqid { t.Fatalf }` so the other half never ran.

  2. An earlier-sorting PLAIN record carrying the victim's host, in a region
     no box serves, made the victim's own box CLEAR the victim's real
     replica link: the rail answered protect=false, the domains pass swept
     the alias, and another box went on minting the victim's home. A live
     pair severed by a record the victim cannot see and cannot delete.

There is no attacker-proof ownership source available to this pass — it
reads records, not the authority behind them — so the rail stops trying to
pick a winner. A host claimed by more than one RecordKey is CONTESTED
(provision.ContestedHosts), and a contested host is never used to vouch for
anything: a replica whose home is contested is protected, a replica whose
OWN host is contested is protected, and buildSiblings writes no file for
either side of such a pairing. Claims are counted off the bucket LISTING
rather than off the decoded records, so a record whose body will not read
this pass still holds its claim — otherwise a read failure hands the shadow
sole ownership and mints the attacker's replica during the blip, which it
did. It is logged once per pass naming both claimants: two records claiming
one instance host is a thing an operator has to see.

Nothing in the pass clears replica_of any more. The SetReplicaOf(host, "")
path adf29ebd added for rails one to three is gone; it was the weapon in the
second break, and protection is the correct fail-safe for every one of these
rails. The argument for clearing was that no door produces those states, so
whatever produced them was outside the doors — but "outside the doors"
includes a writer attacking the account, and clearing was the only
irreversible thing the branch could do. The siblings writer holds the same
line: a directory holding a contested host is left exactly as it is, no
write and no removal, since "nothing built" is otherwise how that pass
learns a placement was withdrawn.

The identity keying of `all` stays — that part was right and is load-bearing.

Both of the verifier's adversarial files are adopted as
replica_adversarial_test.go, every case kept, plus the cases they did not
write: the earlier-sorting shadow refused, the earlier-sorting plain record
not severing a live pair, and the legitimate pair still working when no
shadow exists. Every case runs in BOTH sort orders — the fixture guard is
gone — and each new assertion was verified red against adf29ebd by
overlaying the files onto a `git archive` of it.

Spec §6 now says plainly what these rails are: fail-safe only, they refuse
to vouch and never revoke; a writer holding bucket-wide s3:PutObject (a
region box's IAM role does) can still deny service by contesting a host and
CANNOT be stopped by this pass; and the real fix is narrowing that grant,
which is infrastructure work outside this branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>