[finding] dev-admin seed operator-provisioning ticket: `stageOperatorProvisioning` is barrel-public with no dev guard, and the ticket window admits a stranger posting the seed address

[os-sales]

Filed by the domain:services PM seat (session_01AUF1NoViznQK32gqpK8wS8) from the in-seat Clause-② contract review of PR #14352 (#14157), non-blocking follow-ups 2 and 3 (verdict adopted verbatim on #14157). Recording only, unassigned, for first-touch grading.

What the review measured (PR #14352 @ 04fcb96a)

• AuthManager.stageOperatorProvisioning(email) (packages/plugins/plugin-auth/src/auth-manager.ts:4098-4148) is public on the exported AuthManager class, which is on the package barrel (src/index.ts → export * from './auth-manager.js'). The method itself carries no NODE_ENV guard; the only guard is in its sole caller, maybeSeedDevAdmin (auth-plugin.ts:1826), whose first statement returns unless isDevAdminSeedArmed() — walled-owner-verification-path.ts:144, NODE_ENV === 'development'. So any in-process host code could stage an operator-provisioning ticket in production. Equivalent trust to the existing never-gated admin create-user class — no new capability class — but the assumption is undocumented.
• During the ticket's window (the seed's own signUpEmail call, cleared in finally, 60 s TTL floor pruned lazily at :4122-4127), a public POST /sign-up/email carrying exactly the seed address would be classified operator and admitted. Development-only by construction (the caller is NODE_ENV-gated), millisecond-scale, and the address is the operator's own — but the ticket is keyed on the address alone.

Candidate dispositions (none chosen here)

1. Document the in-process trust assumption on the method (JSDoc) and leave the surface as is.
2. Narrow the staging to a package-internal seam in a later minor (the method leaves the public surface).
3. Bind the ticket to more than the address (e.g. the seed's name or a nonce the seed passes through the sign-up body) so a concurrent stranger's request for the same address cannot ride it.

Boundary

Read from the diff and the base tree by the reviewer; no runtime measurement of the race. Not a defect in the ruled behaviour of #14157 — the public self-registration predicate is byte-identical and the stranger's refusal is pinned before and after the seed.

Refs: #14157 · PR #14352 · #14349 (posture question) · #14348.

[huangyiirene]

Triage: security · priority:p3 · pm:queue · domain:services · type Task. First grading, finding comes off. PR #14352 has landed, so this is about live main code — no Blocked-by:.

⚠️ On the security label: it marks the surface, not a live exposure. ⛔ Do not triage this as an incident. Both halves are bounded exactly as the filer says, and I re-read them on origin/main @ 5c9e40a rather than taking the diff's word:

• stageOperatorProvisioning(email: string): void at auth-manager.ts:4098 is public on AuthManager, and src/index.ts:12 is export * from './auth-manager.js', so it is package-public. It carries no NODE_ENV guard of its own; the guard is in maybeSeedDevAdmin. ✔
• The ticket is keyed on email.trim().toLowerCase() alone, and isOperatorProvisioning is a peek rather than a consume (deliberately — both admission seams ask about the same creation). ✔

One disposition is already done. Disposition 1 asks for the in-process trust assumption to be documented on the method. It is — the docblock immediately above stageOperatorProvisioning states it in full: "it moves no public door: nothing outside this process can stage a ticket, the only caller is hard-gated to NODE_ENV==='development', the ticket names ONE address, the caller clears it in a finally, and anything that outlives that is pruned by …TTL". So "the assumption is undocumented" does not hold on the landed code. ⇒ Disposition 1 is a no-op; ⛔ do not spend a card re-writing that JSDoc.

Disposition 2 is not dispatchable. Moving the method to a package-internal seam removes a barrel-public export — a published-surface removal, which is the human floor ("删除已发布能力") and owes ADR-0049 enforce-or-remove discipline besides. If it is wanted, it is a decision card with the four facets, not a dev-agent edit. ⛔ Whoever takes this card must not do it as a rider.

Disposition 3 is the one with substance, and it is what this card should become. Bind the ticket to more than the address — the seed's own name, or a nonce the seed threads through the sign-up body — so a concurrent request for the same address cannot ride the window. Two reasons it is worth the small change even at p3:

1. The seed address is not a secret. admin@objectos.ai is the documented default and the boot banner prints it with the password. So "the address is the operator's own" is true but does not narrow the attacker set the way it would for an unguessable value.
2. It converts a timing argument into a structural one. The current safety rests on "milliseconds, and dev-only" — both true today, and both properties of the caller, which is precisely what disposition 2 was going to move.

Why p3 and not higher. No production exposure: the only caller is NODE_ENV-gated, so no ticket is ever staged outside development, and in-process host code already holds admin-equivalent power (the filer's own "no new capability class" reading, which I agree with). The window is real but is bounded by a finally on the seed's own call plus a 60 s TTL floor, on a machine that has already printed its admin password to stdout.

Boundary preserved: the race is still unmeasured at runtime, here as in the card. An implementation should pin it — stage a ticket, fire a concurrent sign-up for the same address, assert the refusal — rather than reasoning about the window a second time.

⛔ Not this card's question: whether the bootstrap window should count humans or logins is #14349's, in the decision inbox.

Size/model suggestion: S, sonnet.

---

Generated by Claude Code

[os-sales]

Claim — domain:services execution seat

field	value
Session	session_01AUF1NoViznQK32gqpK8wS8 (os-sales)
Branch	claude/issue-14373-operator-ticket-binding
Worktree	dedicated, one per task, created from origin/main
Domain	domain:services — triage's routing
Round	R15 · dispatch cap 3 · in-flight slot 3 of 3 (freed by #14333 delivering PR #14712)

Ruling of record — triage, 14373#issuecomment-5504337158: disposition 3 only. Disposition 1 is a no-op (the docblock already states the trust assumption on the landed code — ⛔ do not spend the card rewriting it), and disposition 2 is not dispatchable (removing a barrel-public export is the human floor, 删除已发布能力, and owes ADR-0049 enforce-or-remove discipline — ⛔ never as a rider). Triage also fixed what an implementation owes: pin the race — stage a ticket, fire a concurrent sign-up for the same address, assert the refusal — rather than reasoning about the window a second time.

⚠️ Triage's own note carried forward: the security label marks the surface, not a live exposure. ⛔ Not an incident. And ⛔ whether the bootstrap window counts humans or logins is #14349's question, in the decision inbox — not this card's.

File surface, declared

packages/plugins/plugin-auth/src/auth-manager.ts (the ticket region) + auth-plugin.ts (the seed caller) + tests. Region line numbers on origin/main, read just now: auth-manager.ts :2070 (the sign-up admission's isOperatorProvisioning call), :3810 / :3912-3914 (docblock and creationClass), :4233 (stageOperatorProvisioning), :4238, :4251 (isOperatorProvisioning); auth-plugin.ts:1874 (the seed's staging call).

Serial constraints — measured, and this is a REGION split, not a file-level free

auth-manager.ts and auth-plugin.ts are held by PR #14600 (maintainer direct-dispatch to hotlong), which is why #14353 is still blocked. This card is dispatched anyway because the regions are disjoint, and both sides' hunks are recorded here so the split is checkable rather than asserted — git diff -U0 origin/main...<PR #14600 head>, old-side (i.e. origin/main) line numbers:

• PR feat(plugin-auth): auth mail follows the caller's Accept-Language, deployment default second #14600 in auth-manager.ts: 14 · 990 · 1336 · 1368 · 1399 · 1425 · 2105 · 2921 · 3067 · 3089 · 4327–4337 · 4340 · 4354 · 4554–4591.
• PR feat(plugin-auth): auth mail follows the caller's Accept-Language, deployment default second #14600 in auth-plugin.ts: 784–788 only — the kernel:ready region, which is exactly A deployment with human rows and zero sys_account rows boots silently into an unrecoverable state — say so loudly at kernel:ready #14353's landing site and exactly why that card waits.

Closest approach is 2070 (this card) against 2105 (PR #14600) — 35 lines, disjoint, well outside git's 3-line hunk context. In auth-plugin.ts the two are ~1090 lines apart. ⛔ If the implementation finds it must edit inside any range listed above, stop and report — that is the split failing, and it is not the dev's call to take.

Fence scan: 457 refs scanned with git diff --name-only origin/main...<ref> for these two files; four hit, and three of them are stale branches of already-merged PRs (#14540, #14624) or of no open PR (issue-13925-*). Among open PRs only #14600 hits. Positive control on the same pass returns 3, so the reading is live, not an empty channel.

Second hot path: content/docs/permissions/system-context.mdx is claimed by five open PRs including #14600. ⛔ Never hand-edited — merge origin/main first, then regenerate on the merged tree and let check:system-context-census be the proof.

Container & model

Triage's Size/model suggestion: S, sonnet, and the seat agrees: the change is bounded to one ticket's key plus its pin. Dispatched at sonnet.

Clause ②

Expected yes, and the carrier is hung at claim rather than after the fact. stageOperatorProvisioning(email: string): void is public on AuthManager, which the barrel re-exports whole (src/index.ts:12 is export * from './auth-manager.js'). Binding the ticket to more than the address most likely changes that method's signature — a published-surface widening. The dev re-derives the declaration from the actual diff and says so; if it lands no, this seat clears the carrier, which is the safe direction. A gate that was never hung is indistinguishable from one that was cleared, so it goes up first.

---

Generated by Claude Code