fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

the forge token is written into git remote URLs, which defeats the member credential scrub #157

New Issue
Closed
opened 2026-08-23 14:16:12 +02:00 by ltms · 0 comments
ltms commented 2026-08-23 14:16:12 +02:00
Owner
Copy Link
Copy Source

Split out of #156 §5 because it is concrete and fixable on its own.

What

On fleet01, ~/LTMS/kb/.git/config holds the forge token inline in the remote URL:

https://<WORKER_GITEA_TOKEN>@git.ltms.dev/akb/kb.git

Both worker worktrees under ~/LTMS/.fleet-worktrees/ inherit the same URL, because a worktree shares the parent repo's config. The file is mode 664.

Why it matters

The memberCredentials scrub removes environment variables. It cannot remove a token written into a file inside the repository the member is told to work in.

So the guard works exactly as designed and the token still reaches the member. A member that never sees WORKER_GITEA_TOKEN in its environment gets it from:

git remote -v

On fleet01 this is worse than it sounds, because the host's whole credential story is "members are non-login shells, so they inherit nothing". That story is true and good — and this bypasses it completely.

The token is repo-scoped (repo.code/issues/pulls = write via the agents team), so the blast radius is the forge, not the gateway. It is still a credential the member was deliberately not given.

How it was found

By accident, and expensively: I ran git remote -v while surveying the host and printed the token into an operator transcript. It is being rotated.

That is worth recording as part of the defect. Any routine, harmless-looking inspection command prints this credential. git remote -v, git config --list, git remote show origin, and anything that dumps .git/config all leak it, and none of them look like they touch secrets.

Suggested fix

Pick one, and apply it wherever a repo is cloned or provisioned for a member:

  1. ssh remotes. fleetd already pushes over ssh elsewhere and ~/LTMS/fleetd itself uses an ssh remote with no credential in it.
  2. A git credential helper, so the token is supplied at call time and never persisted into config.
  3. http.extraHeader injected at exec time rather than a URL, if https is required.

Option 1 is the smallest change and matches what the repo already does for its own checkout.

Then check the provisioning path: if worktree provisioning copies or inherits a remote URL, fixing the parent clone by hand is not enough — the next clone recreates the problem.

Tests

  • a provisioned worktree's origin URL contains no credential
  • a member can still push and open a PR after the change (the point of the token is that it works)
  • assert on the URL the provisioning code actually writes, not on a helper that formats one — this control is the #113 shape

Not verified

I did not check how ~/LTMS/kb was originally cloned, so I do not know whether fleetd wrote that URL or a human did. That matters for the fix: if a human did it, the code change is prevention rather than repair. Worth confirming first.

Split out of #156 §5 because it is concrete and fixable on its own. ## What On `fleet01`, `~/LTMS/kb/.git/config` holds the forge token inline in the remote URL: ``` https://<WORKER_GITEA_TOKEN>@git.ltms.dev/akb/kb.git ``` Both worker worktrees under `~/LTMS/.fleet-worktrees/` inherit the same URL, because a worktree shares the parent repo's config. The file is mode 664. ## Why it matters The `memberCredentials` scrub removes **environment variables**. It cannot remove a token written into a file *inside the repository the member is told to work in*. So the guard works exactly as designed and the token still reaches the member. A member that never sees `WORKER_GITEA_TOKEN` in its environment gets it from: ``` git remote -v ``` On `fleet01` this is worse than it sounds, because the host's whole credential story is "members are non-login shells, so they inherit nothing". That story is true and good — and this bypasses it completely. The token is repo-scoped (`repo.code/issues/pulls = write` via the `agents` team), so the blast radius is the forge, not the gateway. It is still a credential the member was deliberately not given. ## How it was found By accident, and expensively: I ran `git remote -v` while surveying the host and printed the token into an operator transcript. It is being rotated. That is worth recording as part of the defect. Any routine, harmless-looking inspection command prints this credential. `git remote -v`, `git config --list`, `git remote show origin`, and anything that dumps `.git/config` all leak it, and none of them look like they touch secrets. ## Suggested fix Pick one, and apply it wherever a repo is cloned or provisioned for a member: 1. **ssh remotes.** `fleetd` already pushes over ssh elsewhere and `~/LTMS/fleetd` itself uses an ssh remote with no credential in it. 2. **A git credential helper**, so the token is supplied at call time and never persisted into config. 3. **`http.extraHeader` injected at exec time** rather than a URL, if https is required. Option 1 is the smallest change and matches what the repo already does for its own checkout. Then check the provisioning path: if worktree provisioning copies or inherits a remote URL, fixing the parent clone by hand is not enough — the next clone recreates the problem. ## Tests - a provisioned worktree's `origin` URL contains no credential - a member can still push and open a PR after the change (the point of the token is that it works) - assert on the URL the provisioning code **actually writes**, not on a helper that formats one — this control is the #113 shape ## Not verified I did not check how `~/LTMS/kb` was originally cloned, so I do not know whether `fleetd` wrote that URL or a human did. That matters for the fix: if a human did it, the code change is prevention rather than repair. Worth confirming first.
ltms closed this issue 2026-08-28 01:10:38 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#157
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?