security: a credential resolver returns a token without the cleartext-http check #715

New issue

Closed

opened 2026-10-04 18:59:14 +00:00 by hexajon · 0 comments

hexajon commented

2026-10-04 18:59:14 +00:00

Owner

What happens

madtea resolves forge credentials through a fallback chain. One resolver, GetCredentialsWithSource (internal/config/config.go:545-549), has an environment-variable branch that returns the URL and token without running RequireSecureScheme - the guard that refuses to send a token over a non-loopback http:// connection. The host-keyed and other resolvers run the guard; this branch does not.

Not exploitable today

Every token-bearing request re-runs the guard where it attaches the token, in doAuthedRequest (internal/config/request.go:26-30), and all three current callers of the resolver are verified safe. So nothing leaks today. The gap is latent: a future caller of this resolver could use its result directly and skip the guard, sending a token over cleartext. Low severity: latent, not currently reachable.

Decision

Add RequireSecureScheme in the resolver itself, so the guard cannot be skipped by a future caller. This matches ADR 0041 - the token-security check belongs at the point that carries the token, not at each caller. Non-breaking: an https or loopback setup is unaffected; only a non-loopback http env URL carrying a token is refused, which ADR 0041 already forbids everywhere else.

Acceptance criteria

The environment-variable branch of GetCredentialsWithSource runs RequireSecureScheme before it returns a token.
A test proves the resolver refuses a token for a non-loopback http URL.

## What happens madtea resolves forge credentials through a fallback chain. One resolver, `GetCredentialsWithSource` (`internal/config/config.go:545-549`), has an environment-variable branch that returns the URL and token without running `RequireSecureScheme` - the guard that refuses to send a token over a non-loopback `http://` connection. The host-keyed and other resolvers run the guard; this branch does not. ## Not exploitable today Every token-bearing request re-runs the guard where it attaches the token, in `doAuthedRequest` (`internal/config/request.go:26-30`), and all three current callers of the resolver are verified safe. So nothing leaks today. The gap is latent: a future caller of this resolver could use its result directly and skip the guard, sending a token over cleartext. Low severity: latent, not currently reachable. ## Decision Add `RequireSecureScheme` in the resolver itself, so the guard cannot be skipped by a future caller. This matches ADR 0041 - the token-security check belongs at the point that carries the token, not at each caller. Non-breaking: an `https` or loopback setup is unaffected; only a non-loopback `http` env URL carrying a token is refused, which ADR 0041 already forbids everywhere else. ## Acceptance criteria - [ ] The environment-variable branch of `GetCredentialsWithSource` runs `RequireSecureScheme` before it returns a token. - [ ] A test proves the resolver refuses a token for a non-loopback `http` URL.

hexajon added the

security

severity/low

labels

2026-10-04 18:59:14 +00:00

hexajon referenced this issue

2026-10-05 12:31:14 +00:00

security: a credential resolver returns a token without the cleartext-http check #714

hexajon added a new dependency

2026-10-05 12:34:16 +00:00

#675 epic: v0.20.0 - breaking: clearer ADR tooling and the write guard on every surface

~~hexajon referenced this issue 2026-10-05 12:34:16 +00:00~~