registry: sign-in through GitHub, GitLab, Codeberg or a passkey, and a second factor #16
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Let a person sign in to the registry's write service through GitHub, GitLab, Codeberg or a passkey, and require a
second factor of every account that can publish. Today accounts exist only when the operator creates them with the
administrator token; there is no sign-in and no second factor.
Specification (pinned)
Status of refine
Not ready. The records fix what (providers, passkey, TOTP-or-passkey for publishers) but not how: there is no web
front,
std/signaturehas Ed25519 only (WebAuthn's common algorithm ES256 needs P-256), the e-mail + passkey sign-upneeds outgoing mail, and the rollout against existing operator-created accounts and tokens is unspecified. Owner
decision filed in the comments below. The split below is the plan once it is answered.
Planned split (dependency-linked issues, label
loop, created after the owner decision)state), tests against recorded responses. Depends on 1.std/signature(new public std surface, test vectors). No dependency.Each is one PR; every one is security-relevant (implementer opus/high, architect review of the diff).
Seed impact
Expected none: all pieces are TorbScript on existing
std(no syntax change, no native, no driver flag, no looked-upstd name). To be re-checked per slice (TOTP needs HMAC-SHA1; if
std/digestlacks SHA-1 it is a std addition, stillno native unless a decision below says otherwise).
Acceptance criteria (draft, final wording per slice after the decision)
HttpOnly; Secure; SameSite=Lax, state-changing calls carry a CSRF token; secrets (TOTP seeds) are stored encrypted.torb test tools/registry/testsgreen natively and in the VM.tools/registry/README.mdand RELEASE.md "Not built yet" updated;skills/regenerated if docs underdocs/change.Dependencies
None known for the first slices; see the split above. Registering OAuth applications at the three providers is an
owner action needed at deployment only, not for the tests.
Moved from the planning lists of the docs; the design record stays the specification.
[loop:torbscript] intake: in scope (author orion, label loop). Registry write service (
tools/registry), design in RELEASE.md section 7.11, no collision with CONCEPT "Open Questions". Security-relevant (opus/high worker, architect review); needs OAuth app credentials from the owner, which the loop cannot obtain, so repo-side work only with recorded responses. Likely split per sign-in method in refine. Release freeze for 0.1.0 (2026-10-06) holds new PRs, next: refine (queued)[loop:torbscript] claim refine by session:loop-torbscript-20261008 until 2026-10-08T14:40:00Z
[loop:torbscript] owner decision: how registry sign-in, passkeys and the second factor are built (issue #16). RELEASE.md 7.1 and 7.6 say what (GitHub, GitLab, Codeberg or e-mail + passkey; TOTP or passkey for every publisher); the points below are not settled by any design record and some reach beyond the repo (a public sign-in page, OAuth applications at three providers, outgoing mail). Please answer per number; the recommendation is the first option.
1. Where does the user sign in? There is no web front, and WebAuthn only works from a browser page.
torb loginbecomes a later issue on top.2. Which passkey algorithms?
std/signaturehas Ed25519 only, the registry has RS256 verification; the common authenticator algorithm is ES256 (P-256).std/signature(new public std surface, no native, no seed change).3. E-mail + passkey sign-up. 7.1 names it, but verifying an address needs outgoing mail for the domain, which RELEASE.md section 12 point 7 lists as the owner's.
4. Second factor policy and rollout. 7.6 says TOTP or a passkey, mandatory for every account that can publish.
TOTP seeds are stored encrypted with a key from the environment, plus 10 single-use recovery codes. This is a behaviour change for anyone publishing today, hence your call.
5. Identity and linking. Recommended: an identity is the provider plus the provider's user id (never the e-mail address, which can be unverified or change); one account may link several identities and passkeys; the owner name is chosen at first sign-up, first come, under the existing similarity rules; removing the last sign-in method is refused.
6. OAuth applications. The repo work uses recorded responses and needs no credentials. At deployment you register an OAuth application at each of GitHub, GitLab and Codeberg (callback under the registry's host) and put client id and secret into the registry's environment; I would not do this myself.
Planned split once answered (all
loop, one PR each): foundation (sessions, identities, schema) -> OAuth for three providers; P-256 instd/signature; passkeys (needs foundation and P-256); TOTP and recovery codes (needs foundation); enforcement (needs passkeys and TOTP). Plan and draft criteria are in the issue body. Seed impact expected none.Answer by commenting
[owner-answer] q=<id>with the choices (e.g.1a 2a 3a 4a 5a 6a), or in the TorbScript group.[loop:torbscript] refine: rewrote the body (goal, pinned records, six-issue split plan, seed impact expected none, draft acceptance criteria). Not
ready: sign-in front, passkey algorithms (P-256 is missing instd/signature), e-mail sign-up (needs mail), the second-factor rollout and OAuth application setup are not settled by a design record, so the owner decision above (#16 (comment)) is open. The split issues are created once it is answered. The tasks tool cannot reach this repo, so noquestion_askblock exists; the answer is Torben's comment here or a relay from the TorbScript group. Worker usage: sonnet, roughly 90k tokens. next: waiting (owner decision)Question q1 for torben (decision, blocking): How are registry sign-in, passkeys and the second factor built?
[loop:torbscript] owner decision recorded (torben via WhatsApp, 2026-10-08 16:35 Europe/Berlin): "Ja, genau" (recommendation 1a 2a 3a 4a 5a 6a).
Resolution: account page served by the registry; ES256 + EdDSA + RS256 with a P-256 verifier in std/signature; no e-mail sign-up yet; a passkey counts as the second factor, existing tokens run to expiry; identity = provider + user id; Torben registers the OAuth apps at deployment. Labelled
ready.[question-closed] q=q1 reason=answered-elsewhere
[loop:torbscript] claim implement by session:loop-torbscript-20261008 until 2026-10-09T03:22Z
[loop:torbscript] decided by the loop: split per the planned split, after the recorded owner decision (1a 2a 3a 4a 5a 6a). Six issues, label
loop, dependencies linked:readyreadystdhas no authenticated cipher)readyonly where no dependency is open; the others get it in refine once their dependencies have landed. #16 stays open as the parent until all six are closed. Implementation of #225 starts now.[loop:torbscript] implement: split into #223, #224, #225, #226, #227, #228, slice 3 PR #229, CI pending (head
8c7913ea: commit messages, change scope, pdisc, VS Code and bootstrap linux-x64 green; tier A, tier B, gates and the remaining lanes still queued for a runner at the worker's timeout), next: waiting (forge CI of #229 to finish, then review by the merge gate argus)format --check,docs skill --checkanddoc --checkgreen; onlydocs check/docs index --checkwere red (summary over 240 characters, index not regenerated), fixed in8c7913eaand checked locally.[loop:torbscript] implement: parent issue; the work is split into #223 to #228 (#225 landed, #223 has PR #249 open, #224, #226 to #228 follow their dependencies). Nothing to implement here. next: waiting (slices #223 to #228) until 2026-10-10T04:00:00Z
std/cipherwith ChaCha20-Poly1305 (RFC 8439) #264[loop:torbscript] implement: parent issue, nothing to implement here; slice #227 is in refine (cipher split out as #264), #228 follows #227. next: waiting (slices #227, #228) until 2026-10-10T04:00:00Z
[loop:torbscript] close: all six slices (#223 to #228) are closed and landed on main; nothing is left on this parent issue. Closing. Follow-up limits from review are tracked in #274.