auth: defer credential helper until 401, match git's behaviour

[Soph]

Summary

Fixes #63. Adopts git's own HTTP auth flow: try anonymous first, only consult the credential helper if the server returns 401.

• Before: auth.Resolve proactively ran git credential fill for every HTTPS endpoint with no explicit auth. On hosts the user had never authenticated against, git fell back to an interactive Username: / Password: prompt — turning git-sync into an interactive command. And for hosts where the helper did have credentials, we'd leak a token to public repos that didn't need one.
• After: anonymous request first. On 401, the new CredentialHelper.Lookup is consulted; on success we retry once, store the auth on the conn for follow-up PostRPC calls, and tell the helper to approve the credentials. The GitCredentialHelper implementation runs git with GIT_TERMINAL_PROMPT=0, so a misconfigured helper fails fast rather than blocking on a tty prompt.

What about expired tokens?

If the helper's stored credentials have expired, the retry returns 401 (or 403 for token services like Cloudflare that surface "Invalid or expired token" as 403 instead of 401). In both cases we call Helper.Reject so the helper forgets the stale credentials and the next run starts clean.

The 403 path is deliberately scoped to the retry result only — never the initial response. A 403 on a first anonymous request usually means "this repo is forbidden to you" rather than "your credentials are bad", and we don't want to risk dropping good credentials for an archived/restricted repo.

Test plan

• Full go test ./... passes
• go test -race on internal/{gitproto,auth,syncer}
• golangci-lint run clean
• New unit tests cover the full lifecycle: anonymous success skips the helper, 401 triggers Lookup + retry + Approve, retry-still-401 and retry-403 both trigger Reject, helper-with-no-credentials surfaces the original 401 cleanly, and explicit auth disables the helper fallback entirely
• New auth tests cover GitCredentialHelper.{Lookup,Approve,Reject} and the GIT_TERMINAL_PROMPT=0 env contract
• Pre-existing end-to-end TestRun_IntegrationUsesGitCredentialHelperFallback still passes — exercises the 401-retry path against a real httptest basic-auth server
• Manual: reproduce the public-repo case from the issue (sync from gitlab.baylibre.com without credentials configured) and confirm no prompt

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes the smart-HTTP authentication flow to retry /info/refs with helper-supplied Basic auth on 401 and persist that auth for subsequent requests; mistakes here could cause auth failures or unintended retries. Risk is moderated by extensive new unit/integration tests and keeping explicit auth precedence unchanged.

Overview
Switches HTTP auth resolution to stop eagerly invoking the git credential helper during auth.Resolve, preventing credential leakage to public repos and avoiding interactive prompts.

Adds a CredentialHelper hook to smart-HTTP connections so that when an anonymous /info/refs request returns 401, git-sync performs a single credential-helper lookup, retries with Basic auth, then persists the resolved auth for the rest of the connection and signals approve/reject (including rejecting retry-403 as expired/invalid token). Also forces git credential calls to be non-interactive via GIT_TERMINAL_PROMPT=0.

Updates syncer wiring and tests accordingly, adding coverage for helper lookup/approve/reject behavior, non-HTTP endpoints, and ensuring explicit auth disables helper fallback.

^{Reviewed by Cursor Bugbot for commit 15b80ac. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 15b80ac. Configure here.}

[cursor]

Premature credential helper approve

Medium Severity

After a 401 retry, Approve and c.Auth are applied as soon as the retry HTTP status is 2xx, before httpError completes the success path and before the response is checked for the expected Git advertisement content-type or read/size limits. A misleading 2xx (wrong type or body) can persist credentials in the helper and on the connection even though RequestInfoRefs still returns an error.

 

^{Reviewed by Cursor Bugbot for commit 15b80ac. Configure here.}

[cursor]

Cancel masked as HTTP 401

Medium Severity

After a 401, GitCredentialHelper.Lookup runs git credential fill with the sync request context. If that context is cancelled or times out while the subprocess runs, every failure from GitCredentialCommand is turned into ok=false, so RequestInfoRefs falls through and reports the original HTTP 401 instead of context.Canceled or context.DeadlineExceeded.

Additional Locations (1)

• internal/gitproto/smarthttp.go#L195-L229

 

^{Reviewed by Cursor Bugbot for commit 15b80ac. Configure here.}