oficina / home Public

Review pass: four of the plan's source claims were false, and sign-in could not find a returning person

The plan's shape was right and most of it survives. What did not is
listed here, because each would have become auth code.

Sign-in minted a fresh person ref on every visit. The blind index was
deferred to step 4 as "not settled", leaving a NOT NULL UNIQUE column
with nothing to put in it and no lookup key — so sessions, credentials,
recovery codes and the assertion's sub would all have attached to an
identity nobody could ever return to. Ruling 3 is in the settled table
and supplies the mechanism; it is built in this task now, and
HOME_PEPPER joins the list only Paul can provision. Lose the DEK and
sealed links are unreadable; lose the pepper and every person row is
orphaned.

The magic link redeemed on GET. Mail scanners prefetch links, which
burns a single-use token; worse, any page the victim loads could embed
an img tag pointing at the verify URL and silently sign them into the
attacker's account. §5.6 names login CSRF for the assertion; this is
the same attack one hop earlier. GET now renders a scriptless confirm
form and POST does the work behind csrf.Protect. Cross-device still
works because the token rides the URL, not a cookie.

Redemption was SELECT-then-UPDATE, so two concurrent clicks both
minted. It is one DELETE ... RETURNING now, which also removes the
redeemed_at column and with it the oracle that let a caller tell
"already used" from "never existed" — all three are now no row.

PRAGMA secure_delete: the plan called this its riskiest assumption and
it was right. db.Open's DSN carries busy_timeout, journal_mode and
foreign_keys and nothing else, with no passthrough, and it opens two
pools. secure_delete is per-connection, so an Exec after open sets it
on one connection out of five — and the proposed test would have read
it back on that same connection and passed while proving nothing. It
needs sqlite.RegisterConnectionHook and a test on a fresh connection.

Task 5 dropped the Keymail upgrade entirely: it computed a class no
code path consumed, after the mail had gone. The seam is signin.Flow,
whose Links interface lets the app supply a store that seals in PutLink
and opens in TakeLink. Taking it also brings rate limits on POST
/signin — the plan had none, leaving a mail-bomb vector — plus
CRLF-safe address parsing and a link TTL the plan never named.
signin.ClassKeymail, flagged as the one identifier not verified at
source, does not exist; Class is a struct.

Task 6 claimed rastrillo ships no WebAuthn JS. It does:
webauthn/js.go embeds js/webauthn.mjs and exports webauthn.JS(). So
the ruling §11 needs is only whether one screen may require script, not
who writes it. Struck the fallback that recovery codes could ship
without passkeys: SignInRecovery needs a live half-session and never
signs anyone in from nothing, so codes alone are a first-factor bypass
the spec never authorised.

The RP-ID guard asserted nothing — an undefined helper, a dot count
that is not "the full host", and no mention of LegacyRPID, which is a
second accepted RP ID for assertions. Gate 1's canary was
case-sensitive and not address-shaped, so it was blind to the
lowercased copy that the blind index and the rate limiter both produce.
And §3.4's "failed to hash alice@example.com" is its counter-example,
not a prescribed error string; the plan read it as the latter and would
have shipped the exact leak the rule forbids.

Plus ruling 20 (attributes, not classes), main now existing, the
gate-9 merge-order dependency, and a helpers section so the executor
is not inventing newTestApp, the sessions config, the session TTL or
AuthTime — a zero AuthTime is never fresh, so RequireFresh could never
have passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>