Hardening: repo-scoped-only client mode for dir-resolved services #264

New issue

Closed

opened 2026-07-19 03:19:28 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-19 03:19:28 +00:00

(Migrated from codeberg.org)

Security-audit follow-up, defense-in-depth. The dir= report carve-out (ADR 0027) borrows the target checkout's own credential via GetConfigForDir and builds its service with gitea.NewClientWithConfig(cfg.URL, cfg.Token, "/repos/"+owner+"/"+repo) (internal/mcp/helpers.go:636). The repo-prefix narrows the repo-relative calls, but the constructed HTTPClient still carries the full API surface - /user, /orgs, /admin, search - so the only thing keeping the borrowed token repo-scoped is that the four carve-out handlers happen to call only repo-scoped issue methods.

The getconfigfordir drift guard pins the credential call sites, but it cannot catch a future edit that widens WHAT one of those handlers does with the client it already has - that would ship without tripping any guard.

Proposal: a repo-scoped client mode for dir-resolved services that structurally refuses any request whose path is not under /repos/{owner}/{repo} (constructor flag or wrapper type), so the boundary is enforced by the client rather than by handler discipline. A test asserting the refusal keeps it pinned.

Not a live vulnerability today - the current handlers are verified repo-scoped - purely closing the future-edit gap.

Security-audit follow-up, defense-in-depth. The dir= report carve-out (ADR 0027) borrows the target checkout's own credential via `GetConfigForDir` and builds its service with `gitea.NewClientWithConfig(cfg.URL, cfg.Token, "/repos/"+owner+"/"+repo)` (`internal/mcp/helpers.go:636`). The repo-prefix narrows the repo-relative calls, but the constructed `HTTPClient` still carries the full API surface - `/user`, `/orgs`, `/admin`, search - so the only thing keeping the borrowed token repo-scoped is that the four carve-out handlers happen to call only repo-scoped issue methods. The `getconfigfordir` drift guard pins the credential call sites, but it cannot catch a future edit that widens WHAT one of those handlers does with the client it already has - that would ship without tripping any guard. Proposal: a repo-scoped client mode for dir-resolved services that structurally refuses any request whose path is not under `/repos/{owner}/{repo}` (constructor flag or wrapper type), so the boundary is enforced by the client rather than by handler discipline. A test asserting the refusal keeps it pinned. Not a live vulnerability today - the current handlers are verified repo-scoped - purely closing the future-edit gap.

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#264

No description provided.

Rows
Columns