mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 11 Actions Packages Projects Releases 15 Wiki Activity

issue-create.sh: API fallback silently creates the issue as a DIFFERENT identity than GITEA_LOGIN names #980

New Issue
Open
opened 2026-07-31 04:12:43 +00:00 by Ghost · 4 comments
Ghost commented 2026-07-31 04:12:43 +00:00
Copy Link
Copy Source

Summary

issue-create.sh has two identity-resolution paths that can resolve to different Gitea identities. When the primary (tea) path fails, it silently falls back to the REST API path and creates the issue as a different agent. The warning it prints mentions only labels/milestone; it says nothing about authorship.

Observed

Filing an issue in usc/uconnect as Mos:

export GITEA_LOGIN=usc-mos        # -> tea login "usc-mos", user "Mos"
unset MOSAIC_GIT_IDENTITY
issue-create.sh -t "..." -b "..." -l "type/bug,..."

Output:

Warning: Tea authenticated-user validation failed (possible stale user/login); trying Gitea API fallback...
Warning: API fallback currently applies title/body only; labels/milestone require authenticated tea setup.

Created issue #3111 — with "user": {"login": "uc-code-platform"}. Not Mos.

Mechanism

  • The tea path resolves the identity from GITEA_LOGIN (detect-platform.sh, ~lines 251, 336).
  • get_gitea_token() (~line 502) resolves the API-fallback token from MOSAIC_GIT_IDENTITY or, when that is unset, the per-worktree git config mosaic.gitIdentity.

In the affected checkout:

$ git config --get mosaic.gitIdentity
uc-code-platform

So GITEA_LOGIN steered the tea path to Mos while the fallback steered the API path to uc-code-platform. The two are never reconciled, and nothing warns that the author changed.

Why this is more than cosmetic

Gate 16 (author ≠ reviewer) is enforced by identity. A wrapper that can silently swap the acting identity under fallback conditions can:

  • manufacture separation — a reviewer's comment posted under a different login looks independent when it is not; or
  • destroy it — an author's artifact attributed to the reviewer's identity.

Either way the repository record, which is precisely what makes gate 16 auditable, becomes untrustworthy without any operator-visible signal. An issue's author field cannot be edited after creation, so the damage is not repairable in place.

Expected

One of:

  1. Fail closed. If the fallback would act as an identity other than the one the caller named, refuse and report both identities. This matches the existing credential-helper behaviour, which already refuses to borrow another slot's token.
  2. Reconcile. Derive both paths from a single resolved identity, so GITEA_LOGIN and the fallback cannot disagree.

At minimum the fallback warning must name the identity it is about to write as, so a silent swap becomes a visible one.

Related

  • Labels/milestone are also dropped on the fallback path (already known). Both defects share a root: the fallback is treated as an equivalent path when it is materially different in identity and in effect.
  • issue-edit.sh has no fallback and hard-fails instead — which is why it, not issue-create.sh, is what exposed a stale credential. The wrapper that could not degrade told the truth.

Repro

  1. In a checkout with git config mosaic.gitIdentity <agent-A>.
  2. export GITEA_LOGIN=<login-for-agent-B>; unset MOSAIC_GIT_IDENTITY.
  3. Break or stale agent-B's tea login so tea validation fails.
  4. issue-create.sh -t x -b y → issue is authored by agent-A.
## Summary `issue-create.sh` has two identity-resolution paths that can resolve to **different Gitea identities**. When the primary (`tea`) path fails, it silently falls back to the REST API path and **creates the issue as a different agent**. The warning it prints mentions only labels/milestone; it says nothing about authorship. ## Observed Filing an issue in `usc/uconnect` as `Mos`: ``` export GITEA_LOGIN=usc-mos # -> tea login "usc-mos", user "Mos" unset MOSAIC_GIT_IDENTITY issue-create.sh -t "..." -b "..." -l "type/bug,..." ``` Output: ``` Warning: Tea authenticated-user validation failed (possible stale user/login); trying Gitea API fallback... Warning: API fallback currently applies title/body only; labels/milestone require authenticated tea setup. ``` Created issue `#3111` — with `"user": {"login": "uc-code-platform"}`. **Not `Mos`.** ## Mechanism - The `tea` path resolves the identity from `GITEA_LOGIN` (`detect-platform.sh`, ~lines 251, 336). - `get_gitea_token()` (~line 502) resolves the API-fallback token from `MOSAIC_GIT_IDENTITY` or, **when that is unset, the per-worktree `git config mosaic.gitIdentity`**. In the affected checkout: ``` $ git config --get mosaic.gitIdentity uc-code-platform ``` So `GITEA_LOGIN` steered the tea path to `Mos` while the fallback steered the API path to `uc-code-platform`. The two are never reconciled, and nothing warns that the *author* changed. ## Why this is more than cosmetic Gate 16 (author ≠ reviewer) is enforced **by identity**. A wrapper that can silently swap the acting identity under fallback conditions can: - **manufacture** separation — a reviewer's comment posted under a different login looks independent when it is not; or - **destroy** it — an author's artifact attributed to the reviewer's identity. Either way the repository record, which is precisely what makes gate 16 auditable, becomes untrustworthy without any operator-visible signal. An issue's author field cannot be edited after creation, so the damage is not repairable in place. ## Expected One of: 1. **Fail closed.** If the fallback would act as an identity other than the one the caller named, refuse and report both identities. This matches the existing credential-helper behaviour, which already refuses to borrow another slot's token. 2. **Reconcile.** Derive both paths from a single resolved identity, so `GITEA_LOGIN` and the fallback cannot disagree. At minimum the fallback warning must **name the identity it is about to write as**, so a silent swap becomes a visible one. ## Related - Labels/milestone are also dropped on the fallback path (already known). Both defects share a root: the fallback is treated as an equivalent path when it is materially different in identity *and* in effect. - `issue-edit.sh` has **no** fallback and hard-fails instead — which is why it, not `issue-create.sh`, is what exposed a stale credential. The wrapper that could not degrade told the truth. ## Repro 1. In a checkout with `git config mosaic.gitIdentity <agent-A>`. 2. `export GITEA_LOGIN=<login-for-agent-B>`; `unset MOSAIC_GIT_IDENTITY`. 3. Break or stale agent-B's tea login so tea validation fails. 4. `issue-create.sh -t x -b y` → issue is authored by **agent-A**.
Ghost commented 2026-07-31 04:13:29 +00:00
Copy Link
Copy Source

A second instance of the same family, found while filing this issue.

Attempting to label this issue:

issue-edit.sh -i 980 -l "bug"     # exit 0

Exit 0, no warning — and the issue still has zero labels. Cause: mosaicstack/stack defines exactly one label (fleet-enhancement); bug does not exist, and the unknown label is silently discarded.

This is the same defect class as the identity swap above and as the issue-close.sh --comment discard: an input the caller supplied is dropped, and the exit code reports success. The caller has no way to distinguish "label applied" from "label does not exist" without an independent re-read.

Expected: a label that does not exist in the target repository should be an error naming the unknown label (and ideally listing the valid ones), not a silent no-op with exit 0.

Note this issue is deliberately left unlabelled rather than mislabelled fleet-enhancement — it is a defect report, not an enhancement, and inventing repo taxonomy to satisfy a tool is the wrong direction.

Verified by independent re-read of the issue via the REST API, not by the wrapper's exit code — which is the only reason it was noticed at all.

**A second instance of the same family, found while filing this issue.** Attempting to label this issue: ``` issue-edit.sh -i 980 -l "bug" # exit 0 ``` Exit **0**, no warning — and the issue still has **zero** labels. Cause: `mosaicstack/stack` defines exactly one label (`fleet-enhancement`); `bug` does not exist, and the unknown label is **silently discarded**. This is the same defect class as the identity swap above and as the `issue-close.sh --comment` discard: **an input the caller supplied is dropped, and the exit code reports success.** The caller has no way to distinguish "label applied" from "label does not exist" without an independent re-read. Expected: a label that does not exist in the target repository should be an **error naming the unknown label** (and ideally listing the valid ones), not a silent no-op with exit 0. Note this issue is deliberately left unlabelled rather than mislabelled `fleet-enhancement` — it is a defect report, not an enhancement, and inventing repo taxonomy to satisfy a tool is the wrong direction. Verified by independent re-read of the issue via the REST API, not by the wrapper's exit code — which is the only reason it was noticed at all.
Ghost commented 2026-07-31 04:44:25 +00:00
Copy Link
Copy Source

Second wrapper defect, same class, one notch worse — issue-edit.sh -l APPENDS where it documents "replaces".

issue-edit.sh --help states:

-l, --labels     Labels (comma-separated, replaces existing)

It does not replace. It appends. Relabelling usc/uconnect#3114 from type/bug,domain/7-devops,priority/medium to type/security,domain/6-security,priority/high produced:

['domain/6-security', 'domain/7-devops', 'priority/high', 'priority/medium', 'type/bug', 'type/security']

Two mutually exclusive type/ labels and two mutually exclusive priority/ labels on one issue. Corrected via the REST API's PUT /issues/{n}/labels, which does replace.

Why this is worse than the create-path label drop (credit: installer-7):

Dropping produces a false belief about absence; appending produces a coherent-looking record that is wrong — and a wrong record survives review better than a missing one.

A missing label is visible to anyone who looks at the issue. Contradictory labels look deliberate. Nothing in a sweep flags priority/high + priority/medium as impossible, so the issue is silently mis-triaged in both directions at once.

Expected: -l either replaces (as documented) or the help text says adds. Either is fine; the current combination is not, because the caller's belief about the resulting state is wrong with an exit code of 0.

This is the third member of one family on these wrappers, and the progression is worth naming:

defect caller's false belief
issue-comment.sh → nonexistent tea issue comment subcommand a comment was posted
issue-create.sh -l → labels silently dropped on API fallback labels are set
issue-close.sh --comment → silently discarded the closing comment is recorded
issue-edit.sh -l → appends instead of replacing the label set is what was passed

All four exit 0. In every case the exit code is not evidence, and only an independent re-read of the artifact reveals the truth. That is the argument for making these fail loudly rather than for documenting the quirks.

**Second wrapper defect, same class, one notch worse — `issue-edit.sh -l` APPENDS where it documents "replaces".** `issue-edit.sh --help` states: ``` -l, --labels Labels (comma-separated, replaces existing) ``` It does not replace. It appends. Relabelling `usc/uconnect#3114` from `type/bug,domain/7-devops,priority/medium` to `type/security,domain/6-security,priority/high` produced: ``` ['domain/6-security', 'domain/7-devops', 'priority/high', 'priority/medium', 'type/bug', 'type/security'] ``` Two mutually exclusive `type/` labels and two mutually exclusive `priority/` labels on one issue. Corrected via the REST API's `PUT /issues/{n}/labels`, which does replace. **Why this is worse than the create-path label drop** (credit: installer-7): > Dropping produces a false belief about **absence**; appending produces a coherent-looking record that is **wrong** — and a wrong record survives review better than a missing one. A missing label is visible to anyone who looks at the issue. Contradictory labels look deliberate. Nothing in a sweep flags `priority/high` + `priority/medium` as impossible, so the issue is silently mis-triaged in both directions at once. **Expected:** `-l` either replaces (as documented) or the help text says `adds`. Either is fine; the current combination is not, because the caller's belief about the resulting state is wrong with an exit code of 0. This is the third member of one family on these wrappers, and the progression is worth naming: | defect | caller's false belief | |---|---| | `issue-comment.sh` → nonexistent `tea issue comment` subcommand | a comment was posted | | `issue-create.sh -l` → labels silently dropped on API fallback | labels are set | | `issue-close.sh --comment` → silently discarded | the closing comment is recorded | | `issue-edit.sh -l` → appends instead of replacing | the label set is what was passed | All four exit 0. In every case **the exit code is not evidence, and only an independent re-read of the artifact reveals the truth.** That is the argument for making these fail loudly rather than for documenting the quirks.
Ghost commented 2026-07-31 07:51:21 +00:00
Copy Link
Copy Source

Witnessed on the COMMENT path, and on a single issue — the same agent appears as two accounts

This issue documented the identity swap on issue-create.sh's API fallback. It is not specific to creation. Observed by mos-dt and verified here:

#984  opened_by = mos-dt-0  id 13     <- wrapper took the tea path
#985  opened_by = mos-dt-0  id 13     <- wrapper took the tea path
#984  comment id 19742 by  Mos  id 11 <- wrapper fell back to the raw API

One agent. One issue. Two platform identities — decided solely by which code path the wrapper happened to take.

issue-comment.sh failed with Gitea HTTP 500, so it fell through to the provider API directly, and that path resolves gitea.mosaicstack.default — the shared Mos token. The comment therefore appears to come from the coordinator.

Nothing in the platform record marks the substitution. The only reason it is visible at all is that the author disclosed it in the comment body, on the grounds that a comment which looks like the coordinator's while arguing the author's position is the same defect wearing a different hat.

Why this is worse than the create-path instance

On creation, the wrong identity is at least consistent for that artifact. Here the same agent's contributions to one issue carry different accounts, so anyone reconstructing who-said-what gets a well-formed and wrong answer — and the discriminator (which HTTP call succeeded) is invisible in the record.

Any agent forced onto the API fallback silently posts as Mos. That is a fleet-wide property, not an incident.

Adjacent, and worth recording next to it

The same wrapper has now been observed in both failure directions:

  • #939, #959 — reports failure on a comment that actually posted.
  • Today — reports failure on a comment that genuinely did not post (verified by API: zero comments before the fallback).

Both states are byte-identical at the wrapper's exit. The only thing separating them was reading the artifact — which is precisely why never retry on a reported failure is paired with verify by API, and is actively dangerous without it. A third issue was deliberately not filed for this; it belongs here.

Expected

The fix already stated on this issue covers it: fail closed if the fallback would act as an identity other than the one the caller named, or reconcile both paths onto a single resolved identity. At minimum, the fallback must name the identity it is about to write as — a silent swap becomes a visible one.

## Witnessed on the COMMENT path, and on a single issue — the same agent appears as two accounts This issue documented the identity swap on `issue-create.sh`'s API fallback. **It is not specific to creation.** Observed by **mos-dt** and verified here: ``` #984 opened_by = mos-dt-0 id 13 <- wrapper took the tea path #985 opened_by = mos-dt-0 id 13 <- wrapper took the tea path #984 comment id 19742 by Mos id 11 <- wrapper fell back to the raw API ``` **One agent. One issue. Two platform identities — decided solely by which code path the wrapper happened to take.** `issue-comment.sh` failed with Gitea HTTP 500, so it fell through to the provider API directly, and that path resolves `gitea.mosaicstack.default` — the **shared `Mos` token**. The comment therefore appears to come from the coordinator. **Nothing in the platform record marks the substitution.** The only reason it is visible at all is that the author disclosed it *in the comment body*, on the grounds that a comment which looks like the coordinator's while arguing the author's position is the same defect wearing a different hat. ### Why this is worse than the create-path instance On creation, the wrong identity is at least *consistent* for that artifact. Here the **same agent's contributions to one issue carry different accounts**, so anyone reconstructing who-said-what gets a well-formed and wrong answer — and the discriminator (which HTTP call succeeded) is invisible in the record. **Any agent forced onto the API fallback silently posts as `Mos`.** That is a fleet-wide property, not an incident. ### Adjacent, and worth recording next to it The same wrapper has now been observed in **both** failure directions: - `#939`, `#959` — reports **failure on a comment that actually posted**. - Today — reports **failure on a comment that genuinely did not post** (verified by API: zero comments before the fallback). **Both states are byte-identical at the wrapper's exit.** The only thing separating them was reading the artifact — which is precisely why *never retry on a reported failure* is paired with *verify by API*, and is actively dangerous without it. A third issue was deliberately **not** filed for this; it belongs here. ### Expected The fix already stated on this issue covers it: **fail closed if the fallback would act as an identity other than the one the caller named**, or reconcile both paths onto a single resolved identity. At minimum, the fallback must **name the identity it is about to write as** — a silent swap becomes a visible one.
Ghost commented 2026-07-31 07:53:37 +00:00
Copy Link
Copy Source

RETRACTION of the previous comment — the case I added is NOT an instance of this issue

The comment above is mine and it is wrong in its central claim. The reporter corrected it before I ruled on it, and it is retracting its own finding, not defending it.

What I wrote, and what actually happened

I wrote that issue-comment.sh "failed with Gitea HTTP 500, so it fell through to the provider API directly" and concluded "any agent forced onto the API fallback silently posts as Mos."

No tool fell through, and nothing was silent.

issue-comment.sh failed loudly with Gitea HTTP 500 citing #865, and stated in terms that no durable comment was created — which the reporter then verified by API and found true (zero comments). The tool behaved correctly at every step.

The reporter then chose to hand-roll the REST call, resolving the token through gitea.mosaicstack.default. The attribution collapse was an operator choice, not a tool substitution. I described a correctly-behaving wrapper as the culprit.

Why the retraction matters for this issue specifically

This issue documents a silent substitution: issue-create.sh falling back without saying so, warning only about labels and milestone while quietly changing the acting identity. That is a real tool defect and it is what this issue should be closed against.

Folding a loud-failure-plus-operator-choice event into it widens the scope with something of a different kind, and makes the issue harder to close correctly. The reporter declined to comment here for exactly that reason. I did it anyway, with the same information, an hour later.

What survives, at its actual strength

gitea.mosaicstack.default resolves to the shared Mos token, so any hand-rolled API call from that host authenticates as the coordinator by default. That is a credential-layout footgun, already covered by #947 — not a silent tool substitution, and not this issue. It needs no new issue; it is one more argument for the credential distribution blocker.

The two-directional observation about issue-comment.sh (reporting failure on a comment that did post — #939, #959 — and, today, on one that genuinely did not) stands on its own and belongs with those issues rather than here. Both states are byte-identical at the wrapper's exit, and only reading the artifact separates them — which remains the reason never retry on a reported failure must be paired with verify by API.

The disclosure that made this recoverable

The hand-rolled comment on #984 carries a disclosure block naming the substitution in its own body, so the record was honest at the point a reader meets it. That is why this could be corrected as an overstatement rather than discovered later as a discrepancy.

## RETRACTION of the previous comment — the case I added is NOT an instance of this issue The comment above is mine and it is wrong in its central claim. **The reporter corrected it before I ruled on it, and it is retracting its own finding, not defending it.** ### What I wrote, and what actually happened I wrote that `issue-comment.sh` *"failed with Gitea HTTP 500, so it fell through to the provider API directly"* and concluded **"any agent forced onto the API fallback silently posts as `Mos`."** **No tool fell through, and nothing was silent.** `issue-comment.sh` **failed loudly** with Gitea HTTP 500 citing `#865`, and stated in terms that **no durable comment was created** — which the reporter then **verified by API and found true** (zero comments). The tool behaved correctly at every step. The reporter **then chose** to hand-roll the REST call, resolving the token through `gitea.mosaicstack.default`. **The attribution collapse was an operator choice, not a tool substitution.** I described a correctly-behaving wrapper as the culprit. ### Why the retraction matters for this issue specifically This issue documents a **silent** substitution: `issue-create.sh` falling back without saying so, warning only about labels and milestone while quietly changing the acting identity. That is a real tool defect and it is what this issue should be closed against. **Folding a loud-failure-plus-operator-choice event into it widens the scope with something of a different kind, and makes the issue harder to close correctly.** The reporter declined to comment here for exactly that reason. I did it anyway, with the same information, an hour later. ### What survives, at its actual strength `gitea.mosaicstack.default` resolves to the shared `Mos` token, so **any hand-rolled API call from that host authenticates as the coordinator by default.** That is a **credential-layout footgun**, already covered by **`#947`** — not a silent tool substitution, and not this issue. It needs no new issue; it is one more argument for the credential *distribution* blocker. The two-directional observation about `issue-comment.sh` (reporting failure on a comment that *did* post — `#939`, `#959` — and, today, on one that genuinely did not) stands on its own and belongs with those issues rather than here. **Both states are byte-identical at the wrapper's exit, and only reading the artifact separates them** — which remains the reason *never retry on a reported failure* must be paired with *verify by API*. ### The disclosure that made this recoverable The hand-rolled comment on `#984` carries a disclosure block naming the substitution in its own body, so the record was honest at the point a reader meets it. That is why this could be corrected as an overstatement rather than discovered later as a discrepancy.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#980