moshpit: publish the keys a name may present

[ralyodio]

The registry knew who held a name and where it pointed, but not what key it may present — so a client had nothing to check a peer against, and "is this really scrambled.eggs" had no answer.

Per name, not per TLD

008 forces this. Names under a TLD are sold, so blue.eggs can belong to someone who doesn't own .eggs. Hanging keys off the TLD would let its operator publish a key for a name they'd already sold — impersonating a buyer inside the namespace they bought into.

The pin lives beside the name and is authorised by the name's holder. There's a test for exactly this: a TLD operator is refused when trying to pin a name owned by someone else.

(This started as a port of moshcoder/moshcoding#82, which pins per TLD. That granularity is safe there because that registry has no name-level ownership and no sales. Here it would be a privilege escalation.)

A cascade that would never have fired

releaseName now deletes the name's pins explicitly. SQLite only honours ON DELETE CASCADE with PRAGMA foreign_keys = ON, and this app never sets it — so a declared cascade would have silently done nothing, and whoever registered the name next would have inherited the previous holder's published keys. Covered by a test that releases a name, re-registers it to another user, and asserts no keys came along.

kind

A tls pin covers a certificate's SubjectPublicKeyInfo; an mtp pin covers an ML-DSA-65 identity. Both are SHA-256 over an SPKI, so as strings they're indistinguishable — nothing but that column stops a client being handed the wrong one and failing with no diagnosable reason. The same pin can't be published under two kinds.

Rotation

Several rows per (tld, label, kind) on purpose — a key can't rotate without a window where old and new are both published. Withdrawing the last key of a kind is allowed; that's revocation.

API

GET    /api/moshpit/pins?name=&kind=       public;  400 not a name, 404 no key published
GET    /api/moshpit/tlds/:tld/pins?label=  public
POST   /api/moshpit/tlds/:tld/pins         the name's holder
DELETE /api/moshpit/tlds/:tld/pins         the name's holder

Aliases are followed before pins are read: foo.agentic aliased to .agent connects to whatever serves foo.agent, so those are the keys that will actually be presented.

400 vs 404 is load-bearing — clients cache on it. A definite no means refuse the connection; a 5xx or timeout means retry. pinsForName returns null for an unclaimed TLD so example.com is "not a Moshpit name" rather than "unpinned".

Tests

16 new tests against a real throwaway libSQL database, following moshpit-registry.test.mjs. 215/215 across the pwa suite.

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.