ux(whoami): auth whoami green-lights a split-brain repo - no cross-check between resolved forge, origin host, and the resolved repo #200

New issue

Closed

opened 2026-07-17 14:31:12 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-17 14:31:12 +00:00

(Migrated from codeberg.org)

Repro

In the #197 split-brain repo (local madtea.url -> gitea.example from repo config, origin -> codeberg.org):

madtea auth whoami
# URL:    https://gitea.example
# User:   claude
# Source: repo config
# Server: OK (authenticated as claude)
# Repository: sixfold_space/madtea
# ... all five scope probes [ok] ...
# Read access verified for all scopes

Everything reads green while every repo-scoped command in this checkout 404s. whoami is the diagnostic command - the one thing a stuck user runs - and it displayed the contradiction (gitea URL next to a codeberg-parsed slug) without noticing it, in the exact session where noticing it would have ended the incident.

Gaps

No host cross-check. whoami prints the resolved forge URL and the origin-parsed repo slug side by side but never compares the two hosts. When madtea.url's host differs from the origin remote's host, that is a five-alarm configuration smell (a poisoned override per #197, or a deliberate-but-unusual setup) and deserves a loud warning naming both hosts, both sources, and the remedy.
No repo-level probe. The scope audit verifies the TOKEN (user/notification/organization/issue/repository read) but never asks the resolved forge whether the resolved repo exists: one GET /repos/<slug> against the resolved URL would have turned "all green" into "repo sixfold_space/madtea does not exist on gitea.example". Scope-OK plus repo-404 is precisely the split-brain signature.
"Server: OK" overstates. It means "the token authenticates against the forge URL", but sits directly above Repository: <slug>, reading as "this repo is good to go". With gap 2 closed, the repo line can carry its own verified status.

Expected

Repository: sixfold_space/madtea   [NOT FOUND on gitea.example]

Warning: forge mismatch - madtea.url (repo config) points at gitea.example,
but origin points at codeberg.org. Repo-scoped commands will target gitea.example
and fail. If codeberg.org is correct: git config --unset madtea.url

One extra GET per whoami run (repo-scoped invocations only) buys the diagnosis; the mismatch warning itself is free - both hosts are already resolved in-process.

#197 - the incident; fixes the cause, this makes whoami able to see the disease class at all.
#155 (open) - smallest-scope identity for dir= targets; same theme of whoami telling the truth about scope.
#199 - sibling issue: the 404 errors themselves carry the same context and mismatch note.

## Repro In the #197 split-brain repo (local `madtea.url` -> gitea.example from repo config, origin -> codeberg.org): ``` madtea auth whoami # URL: https://gitea.example # User: claude # Source: repo config # Server: OK (authenticated as claude) # Repository: sixfold_space/madtea # ... all five scope probes [ok] ... # Read access verified for all scopes ``` Everything reads green while every repo-scoped command in this checkout 404s. whoami is the diagnostic command - the one thing a stuck user runs - and it displayed the contradiction (gitea URL next to a codeberg-parsed slug) without noticing it, in the exact session where noticing it would have ended the incident. ## Gaps 1. **No host cross-check.** whoami prints the resolved forge URL and the origin-parsed repo slug side by side but never compares the two hosts. When `madtea.url`'s host differs from the origin remote's host, that is a five-alarm configuration smell (a poisoned override per #197, or a deliberate-but-unusual setup) and deserves a loud warning naming both hosts, both sources, and the remedy. 2. **No repo-level probe.** The scope audit verifies the TOKEN (user/notification/organization/issue/repository read) but never asks the resolved forge whether the resolved repo exists: one `GET /repos/<slug>` against the resolved URL would have turned "all green" into "repo sixfold_space/madtea does not exist on gitea.example". Scope-OK plus repo-404 is precisely the split-brain signature. 3. **"Server: OK" overstates.** It means "the token authenticates against the forge URL", but sits directly above `Repository: <slug>`, reading as "this repo is good to go". With gap 2 closed, the repo line can carry its own verified status. ## Expected ``` Repository: sixfold_space/madtea [NOT FOUND on gitea.example] Warning: forge mismatch - madtea.url (repo config) points at gitea.example, but origin points at codeberg.org. Repo-scoped commands will target gitea.example and fail. If codeberg.org is correct: git config --unset madtea.url ``` One extra GET per whoami run (repo-scoped invocations only) buys the diagnosis; the mismatch warning itself is free - both hosts are already resolved in-process. ## Related - #197 - the incident; fixes the cause, this makes whoami able to see the disease class at all. - #155 (open) - smallest-scope identity for dir= targets; same theme of whoami telling the truth about scope. - #199 - sibling issue: the 404 errors themselves carry the same context and mismatch note.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#200

No description provided.

Rows
Columns