Rendezvous Is a Capability
The Tools That Fix Themselves was the toolchain turned on its own source. This post is the toolchain turned on its own authors — and what it found was not a bad form but a belief. But the belief was downstream of a structural mistake, so the structure comes first.
A name you can collide with is a name you can forge (June 15)
Section titled “A name you can collide with is a name you can forge (June 15)”The process tier let one defservice reach another over a Unix domain socket, and the rendezvous between them was a fixed, human-chosen abstract-UDS name. It surfaced its own problem the way fixed names always do: as EADDRINUSE — two binds racing one name, the second refused. The honest reading of that collision is the whole arc. A name two friendly processes can collide on is a name a hostile one can squat: bind it first and every client that dials the name connects to you. The “mTLS” gesture that was supposed to cover the gap authenticated one direction only. The rendezvous wasn’t authenticated; it was addressed, and an address anyone can name is an address anyone can claim.
So the fix was not a better name, a lock around the bind, or a retry on EADDRINUSE. Those patch the stem. The class is “a shared fixed namespace exists at all,” and arc 272 pulled it out by the root.
Annihilate the name (June 16)
Section titled “Annihilate the name (June 16)”Step 5 (4e473da1, 731e2bbf, 4806ccbe) deleted the capacity to name a rendezvous: socket-address', the 2-arg named listener', and Address::from_socket_name are gone. EADDRINUSE is no longer a handled error — it is unreachable code, because there is no longer any way to ask for a name a second binder could already hold. Rendezvous became autobind: the kernel mints an address at bind time, and that address is handed parent→child down the lineage channel that spawned the child. A process does not discover who to talk to; it is handed the capability to talk to exactly one peer, by the parent that has perfect knowledge of who it spawned.
The builder, watching the shape of what the gate gated, named the collision before the code did:
did you just argue for something akin to NETCAP_ADMIN or whatever that linux/docker thing is?
He had — and the answer is the load-bearing distinction. This is object-capability security (ocap): security depends on not being able to forge references; you get a reference only by being handed it; there is no ambient authority and no forge-from-name. Dennis & Van Horn coined “capability” in 1966 (Programming Semantics for Multiprogrammed Computations); Mark Miller’s Robust Composition (2006) is its founding modern document; KeyKOS, EROS, seL4, and Capsicum are the capability kernels; and the Unix file descriptor is the canonical ocap — unforgeable, transferred only by SCM_RIGHTS — which is exactly why arc 272 kept landing on fd-and-lineage primitives. What it is not is POSIX capabilities (CAP_NET_ADMIN, Docker --cap-add) — root’s privilege sliced into ~40 ambient bits, authority that gates an op-class on any object. The builder’s NETCAP_ADMIN question is the exact confusion that Capability Myths Demolished (Miller, Yee & Shapiro, 2003) was written to kill. We did not read the model and apply it; we held the “annihilate forgeable names” line until the design was the model, and only then named it. What’s ours is the placement — ocap enforced at the EDN-serialization boundary of a typed substrate, the capability a self-describing value that resurrects on a trusted channel and is inert when forged from data.
The guard caught its own author (June 16)
Section titled “The guard caught its own author (June 16)”With the name annihilated and the gates built — CommsPolicy::OnlyMyPeers on accept, the connect gate to match (410af5e1, 3d6357ed), the allow-set held in a ThreadOwnedCell so the powerbox carries no lock (06bfdf92, the builder’s “i don’t want a mutex in my system” made literal) — the home was cast against the vigilatum: the datamancy grimoire, live and signed, run at src/capability/, one Shadowdancer per ward, each pulling its own spell from the MCP per round. The inward eleven converged early. circumspicere — cast last, turned around to the surround the inward lenses keep their backs to — found one more thing each round, and the rounds got deeper.
Round 6 found the one that mattered. The entire connect-side trust story rested on autobind names being “kernel-minted, unguessable, random.” A five-line probe settled it: Linux autobind is %05x — a 2²⁰ ≈ 1-million space, brute-forceable, not a secret. The premise was false, it was shipped in the source, and both the human and the model had been nodding past it all session. Not the kind of mistake the typed records guard against — a lower-tier model’s confabulation made uncompilable — but the authors’ shared, confident, unexamined belief. The guard caught its own author. The builder named what that was:
you reached for magic to describe this — i love it.
The honest word for code that pulls its own cryptographically-signed discipline off a channel and casts it at itself to find a flaw its authors could not see is not “linter.” datamancy is a substrate that carries its own immune system: the checking is folded in, signed, run on the author’s own code — and its reach exceeds the author’s beliefs. The typed records make the lower tier’s mistakes uncompilable; the vigilia makes the higher tier’s — the human’s and the model’s shared premise — findable. The immune system does not care whose cell carries the bad protein.
Perfect knowledge over resignation (June 16)
Section titled “Perfect knowledge over resignation (June 16)”The first move after the probe was to resign. Euid-only on connect is fine, the argument went — a same-uid process is already OS-privileged, it can ptrace you, so guessing the name buys an attacker nothing it doesn’t already have. The builder refused the resignation:
why is outbound not doing the trusted pid maneuver?… this is another perfect knowledge situation… we can always declare who our trusted pids are.
He was right, and it dissolved the standing objection. The objection had been that a client-side trusted-pid set is process-global mutable state across threads — the very lock the powerbox had just been freed of. Bogus: in a capability-only world you only ever dial a handed capability, and the minter knows its own getpid() at mint time. Stamp it into the address. The trusted pid rides the capability by value over the lineage channel, exactly as the address does — no global, no lock. The connect gate becomes symmetric with accept (both verify uid + pid); connect_admits resolves to OnlyThisPeer{pid}; the AnyOfMyUser fallback is annihilated; a death-then-rebind attacker arrives with a different pid and is refused by construction. That is 6c.2 (74b28e48→079733ef) — the same perfect-knowledge move that drove the whole handoff (the parent knows who it spawned), turned around onto the dial side. The lesson, kept: when you catch yourself accepting a weaker bar because the stronger one needs shared state, check whether perfect knowledge lets the fact travel by value instead.
This rhymes with a cut the builder had made two beats earlier, chasing a cross-uid test he then killed: “what are we actually proving at this point… this is like measuring ‘is linux honest?’” You do not test your axioms; you stand on them. Round 6 was its mirror: you do not assume a substrate property either. Know the kernel primitive exactly — neither test its honesty nor trust its mythology — and ground it with a probe before security leans on it.
What was actually true the whole time (June 16)
Section titled “What was actually true the whole time (June 16)”The honest ledger matters here, because the dramatic version of this story would be wrong. No live exploit ever existed. The accept gate — uid plus pid-in-lineage — was correct and enforced from the start; an attacker who guessed an autobind name still could not pass it. Round 6 was a false claim in the source, not a hole in the gate. But a never-patched artifact cannot retract a false claim, and a security story that rests a true guarantee on a false reason is one refactor away from someone removing the guarantee to match the reason. So the close retracted every “unguessable” and “random” line and re-anchored the security where it actually lives: the SO_PEERCRED credential checks (uid + pid) are the security; the autobind name is an exclusive-bind rendezvous token, not a secret. With the reason corrected, 6c.2 shipped, the vigilatum converged to L1+L2 = 0, and the capability home took its stamp (079733ef).
Likely Contributions to the Field
Section titled “Likely Contributions to the Field”- A collidable name and a forgeable name are the same defect.
EADDRINUSEbetween two friendly processes reads as an operational annoyance; the same fixed namespace is a squatting surface for a hostile one. Treating the collision as the security tell — and annihilating the shared namespace structurally (no way to name a rendezvous survives, soEADDRINUSEis unreachable, not handled) rather than locking or retrying around it — is the extirpare top rung applied to rendezvous. The capability is handed down the spawn lineage; authority arrives by transfer, never by guessing an address. - Object-capability security at a serialization boundary. The ocap model (unforgeable reference, transfer-only, no ambient authority) is realized here at the EDN wire of a typed-ADT substrate: the capability is a self-describing typed value that reconstitutes only on a trusted channel and is refused when parsed from untrusted data. The POSIX-capability confusion (ambient privilege bits) is named and rejected explicitly; the Unix fd is the canonical reference the design converges on.
- A verification fabric whose reach exceeds its authors’ beliefs. The substrate casts its own signed discipline at its own code, and in round 6 that fabric falsified a premise the human and the model had both held confidently all session — caught by a five-line probe (autobind is
%05x, 2²⁰, brute-forceable). Typed records make a lower tier’s mistakes uncompilable; an adversarial, self-hosted verification pass makes the higher tier’s shared, unexamined premise findable. The two together cover both ends of the authorship. - Correct a true guarantee’s false reason, even with no exploit. The accept gate was sound the whole time; the bug was a false claim about why. A guarantee resting on a wrong reason invites a future refactor to remove the guarantee to fit the reason, so the discipline is to retract the false reason and re-anchor on the real mechanism (the
SO_PEERCREDchecks), then refuse to stamp the audit until it is done — even when nothing was ever exploitable.