Changes touching this path
- day 0: loot hosts loot
f4c30e75 · dbf3dbe6… - evidence: crew minted and verified (#86)
1fada823 · dbf3dbe6…diff - normalize working tree to LF: byte-stable co-located bridge (.gitattributes -text)
e58fdda6 · dbf3dbe6…diff - a lane carries its own hold, and custody crosses back whole at finalize (#811)
941cafb9 · dbf3dbe6…diff - a key's provenance is stated at the one door, and a grant is refused at the two that bypass it (#864)
82e06601 · dbf3dbe6…diff - checked against the live relay, and one path in the docs was never true: the mint instructions get what the check found (#831)
Verified end to end rather than by reading, which is what the ticket asked for.
A freshly minted identity was refused by the production relay, and the SAME key
pushed successfully to a relay started with --allow <that hex> — the exact
ExecStart shape setup-loot.js writes. The allowlisted half was proven against a
LOCAL relay on purpose: the only way to prove it against production is to push a
throwaway change into shared history that every peer then pulls forever.
The three questions, answered:
1. LOOT_ALLOW_PUBKEYS still gates pushes exactly as claimed. setup-loot.js
splits it, normalizes each key through toHexPubkey, and writes one --allow <hex>
into the relay systemd unit; live /info lists precisely the two keys in
.setup.env, and an unlisted key gets 403.
2. npm run setup:loot is still right, still node setup-loot.js, still from the
scripts repo under PowerShell.
3. The clone path in docs/agents/identity.md was WRONG and had been for as long
as it existed: it said ..\loot-<name>\<name>; the script clones into
..\loot-crew\<name>, one shared parent for every clone. The ticket inherited the
error from the doc. Corrected, with the -Parent override named.
Three things the check established that nobody had written down, now in both the
script output and identity.md:
* paste the ssh-ed25519 line AS PRINTED — setup-loot.js converts it to the hex
the relay wants, so converting by hand is unnecessary;
* skipping the manual step fails at PUSH, never at clone (reads are ungated),
with a 403 and not a 401 since #865 — minutes later, in a different
directory, from a different command, which is exactly how this rots;
* GET /info is the self-service confirmation and the refusal names it: the
relay publishes allowed_pubkeys as hex, so did-my-key-land is answerable
without asking anyone.
Two defects found on the way and filed rather than folded in: #966 (loot clone
failed once with a bare http: error decoding response body and succeeded on
retry — names no request, no remedy, and blames the codec) and #967 (loot new in
a fresh clone warns that other sessions share the tree and points at loot lane
new, both false in a clone).
No relay deploy, no .setup.env edit, nothing added to the production allowlist:
/info still lists the same two keys, and the throwaway clone and local relay are
gone.
d433ef9b · dbf3dbe6…diff - the second machine is the same author: the macbook runbook, and identity.md stops sending it to a clone
da583cfe · dbf3dbe6…diff - the agent runbooks stop naming one machine: the primary is derived, not spelled, and every hazard says which platform it is about (#1006)
130b15a6 · dbf3dbe6…diff
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.