bug(config): GetConfigForDir never reads the target dir's own repo-local token — the ADR 0019/0027 contribute flow fails for repo-config-authed clones #94

New issue

Closed

opened 2026-07-15 15:14:40 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-15 15:14:40 +00:00

(Migrated from codeberg.org)

Observed 2026-07-15 while landing ADR 0027 (PR #92): the sanctioned foreign-contribution flow (ADR 0019: worktree → madt_finish dir= branch=) failed against a target checkout whose token lives in repo-local git config — which is exactly how that clone is authed (its own madtea auth whoami reports Source: repo config and authenticates fine). The finish had to fall back to the CLI run from inside the target checkout.

Cause: GetConfigForDir (internal/config/resolve_dir.go:54) resolves the URL from the target dir's chain (dir-local madtea.url → origin → global) but delegates the token to GetConfigForURL, which consults only the env override and the host-keyed secure backend. It deliberately skips the process cwd's plaintext madtea.token — correct, that's ADR 0025's anti-cross-forge-reuse rule — but the target dir's own repo-local madtea.token is skipped as collateral. No code path reads runGitDir(dir, "config", "--local", "--get", "madtea.token").

Under ADR 0027 that's backwards for the sanctioned crossings: the target checkout's own repo-scoped credential is the most scope-coherent source there is — it's that clone doing precisely its configured job against its own origin (the same coherence argument that admits the carve-outs at all). The cwd's token must stay excluded; the dir's own must be admitted.

Fix: in the GetConfigForDir chain, after the secure-backend miss, read dir-local madtea.token (and madtea.user) from the target repo's --local git config scope, paired with the URL already resolved from that same dir. Never the merged/global view (a global plaintext token is the cwd-adjacent reuse case), never another repo's local scope. The per-dir cache already isolates the result.

Acceptance:

madt_finish dir=<foreign clone> branch=<b> succeeds when the target's token is stored repo-locally (today's failure), demonstrated against a clone with no secure-backend entry for its host.
A dir whose repo config has no token and whose host misses the backend still fails closed with "no credentials for " (and #93 makes that error visible through finish).
The process cwd's plaintext token is still never used for a different dir/forge (existing ADR 0025 tests stay green).

Refs ADR 0027 (carve-out 1 is unusable for repo-config-authed targets without this), ADR 0025, #93 (the masking that hid this), #90 (the enforcement work should treat dir-local-token-for-dir's-own-origin as the sanctioned shape).

Observed 2026-07-15 while landing ADR 0027 (PR #92): the sanctioned foreign-contribution flow (ADR 0019: worktree → `madt_finish dir= branch=`) failed against a target checkout whose token lives in **repo-local git config** — which is exactly how that clone is authed (its own `madtea auth whoami` reports `Source: repo config` and authenticates fine). The finish had to fall back to the CLI run from inside the target checkout. Cause: `GetConfigForDir` (internal/config/resolve_dir.go:54) resolves the *URL* from the target dir's chain (dir-local `madtea.url` → origin → global) but delegates the *token* to `GetConfigForURL`, which consults only the env override and the host-keyed secure backend. It deliberately skips the **process cwd's** plaintext `madtea.token` — correct, that's ADR 0025's anti-cross-forge-reuse rule — but the **target dir's own repo-local `madtea.token`** is skipped as collateral. No code path reads `runGitDir(dir, "config", "--local", "--get", "madtea.token")`. Under ADR 0027 that's backwards for the sanctioned crossings: the target checkout's own repo-scoped credential is the most scope-coherent source there is — it's that clone doing precisely its configured job against its own origin (the same coherence argument that admits the carve-outs at all). The cwd's token must stay excluded; the dir's own must be admitted. Fix: in the `GetConfigForDir` chain, after the secure-backend miss, read dir-local `madtea.token` (and `madtea.user`) from the target repo's `--local` git config scope, paired with the URL already resolved from that same dir. Never the merged/global view (a global plaintext token is the cwd-adjacent reuse case), never another repo's local scope. The per-dir cache already isolates the result. Acceptance: - `madt_finish dir=<foreign clone> branch=<b>` succeeds when the target's token is stored repo-locally (today's failure), demonstrated against a clone with no secure-backend entry for its host. - A dir whose repo config has no token and whose host misses the backend still fails closed with "no credentials for <host>" (and #93 makes that error visible through finish). - The process cwd's plaintext token is still never used for a different dir/forge (existing ADR 0025 tests stay green). Refs ADR 0027 (carve-out 1 is unusable for repo-config-authed targets without this), ADR 0025, #93 (the masking that hid this), #90 (the enforcement work should treat dir-local-token-for-dir's-own-origin as the sanctioned shape).

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

No description provided.

Rows
Columns