Document coreapi.New Token Trust Gate Omission
coreapi.New ENTIRE_TOKEN bypass omits the cluster-trust gate it claims parity with (client.go:44-54) The comment says this "Mirrors the env-token path in cmd/git-remote-entire/main.go:resolveCreds", but it only mirrors detection + aud-derivation, not the security gate that path performs — and that omission contradicts the explicit contract on CoreURLFromEnvToken (env_token.go:27): "the caller MUST additionally verify the URL is a trusted core for the target cluster (clusterdiscovery.ResolveClusterCores) before exchanging, or a forged aud could redirect the token to an arbitrary host." git-remote-entire honors this in resolveEnvTokenCreds (ResolveClusterCores + coreTrusted, anchored to the clone-URL host the user typed, main.go:281-288). coreapi.New does not, and cannot in the same way: control-plane commands have no user-supplied host to anchor against. So coreURL comes solely from the token's UNVERIFIED aud claim (ParseClaims does not check the signature) and the verbatim token is then sent as Authorization: Bearer to that host. Practical severity is low — the token IS the credential, so aud-redirection to an attacker host requires already possessing a valid token to re-aud it; there is no privilege-escalation value. The real problems are: (1) the comment overstates parity with the git-remote path — the one security control that path adds is exactly the one absent here, which a future reader will trust; (2) the CoreURLFromEnvToken doc mandates a gate this caller silently skips. Recommendation: drop the "mirrors" framing and state explicitly WHY the trust gate is absent (no clone-URL anchor exists for control-plane commands; the token is its own credential so aud-redirection has no escalation value). Secondary: git-remote uses the env token as an STS subject_token (exchanged via repocreds), never as the final credential; coreapi uses it verbatim as the control-plane bearer. The PR body is upfront about this, but it is another reason the "mirrors" framing is misleading.
Done. This was a comment-accuracy fix only — no behavior change.
The finding was correct on all counts, so I rewrote the comment in coreapi.New (internal/coreapi/client.go:31) to:
- Drop the misleading "Mirrors … resolveCreds" framing. The git-remote path's one distinguishing security control (the cluster-trust gate) is exactly the one this path lacks, so "mirrors" was the wrong claim for a future reader to inherit.
- State explicitly why the gate is absent, addressing the contract in
CoreURLFromEnvToken's doc (env_token.go:27):- Control-plane commands have no user-supplied resource host to anchor against, so
coreURLcould only ever be the token's own unverifiedaud— gating it against itself is meaningless. - aud-redirection carries no escalation here because the token is sent verbatim as the bearer (vs. git-remote using it as an STS
subject_tokenexchanged viarepocreds) — the token IS the credential, so re-aud'ing it requires already holding a valid token.
- Control-plane commands have no user-supplied resource host to anchor against, so
Build and gofmt are clean. Since this only touches a comment I didn't run the full mise run check, but flag that the project requires mise run check to pass before any commit — say the word and I'll run it.
commit changes
Per your workflow, I'll run the required checks first, then show you the draft for confirmation before committing.
commit changes
Committed as 067d66a84 on branch entire_token.
Note: I skipped mise run check since you interrupted the mise trust step — the change is comment-only so it won't affect tests, but CI runs lint/test and mise.toml isn't trusted in this workspace. If you want me to run the check before you push, trust mise yourself (mise trust) and let me know.