Summary

The HTTP transport's redirect handling had several security gaps compared to canonical git's default http.followRedirects = initial policy. This PR closes them.

Problem

When go-git's HTTP transport follows server redirects during Handshake (the GET /info/refs discovery request), several things could go wrong:

1. No redirect policy — Go's default http.Client follows redirects on every request (GET, POST, etc.). A malicious server could redirect a pack-data POST to an attacker-controlled host and the client would silently follow it. Canonical git only follows redirects on the initial /info/refs request and treats 3xx on subsequent requests as errors.

2. No protocol/scheme restriction — A redirect to file://, gopher://, or any other scheme was accepted. This is an SSRF vector in server-side environments. Canonical git restricts redirect targets to http/https/ftp/ftps via CURLOPT_REDIR_PROTOCOLS.

3. Silent fallback on path mismatch — If the redirect target's path didn't end with /info/refs, applyRedirect silently returned the original base URL instead of erroring. Canonical git's update_url_from_redirect() calls die() here because a tail mismatch could indicate a malicious redirect attempting to rewrite the base URL to an unrelated repository.

4. Credential leakage to redirect target — Both the URL-embedded Userinfo credentials and the Authorizer callback were stored in the session and re-applied on every subsequent POST. After a cross-host redirect, the original host's credentials would be sent to the new host. Canonical git re-derives credentials from the new URL via credential_from_url(), effectively wiping the old ones.

Changes

• common.go — applyRedirect now returns (*url.URL, error). Validates the redirect target's scheme is http or https. Returns a hard error when the redirected path doesn't end with /info/refs (matching canonical git's die() behavior).

• http.go — Adds a CheckRedirect policy (checkRedirect) implementing canonical git's initial mode: only the /info/refs GET (tagged via context key) is allowed to follow redirects. Non-initial requests, unsupported schemes, and >10 hops are rejected. Go's stdlib already strips Authorization on cross-host redirects and preserves it for same-host redirects, so no manual header manipulation is needed.

• handshake.go — Tags the /info/refs request with withInitialRequest(ctx). After applyRedirect, clears both URL.User and the Authorizer callback when the host changed — both are credential sources that would otherwise leak to the redirect target.

Canonical git reference

• Redirect policy: http.c:130 (HTTP_FOLLOW_INITIAL default), http.c:1583-1591 (CURLOPT_FOLLOWLOCATION per-request)
• Protocol whitelist: http.c:991-1013 (get_curl_allowed_protocols)
• Tail validation: http.c:2243-2293 (update_url_from_redirect)
• Credential wipe: http.c:2354-2360 (credential_from_url after redirect)

Test plan

• TestCheckRedirectPolicy — unit tests for the checkRedirect function: blocks non-initial requests, allows initial requests, blocks unsupported schemes, blocks >10 redirects
• TestApplyRedirect — unit tests for applyRedirect: no-op detection, host/scheme/path updates, scheme rejection, tail mismatch error
• TestRedirectPostBlocked — integration test: server proxies GET but 307-redirects POST; verifies fetch fails with "non-initial request"
• TestRedirectStripsCredentials — integration test: cross-host redirect clears URL.User from the session's base URL
• TestRedirectPath, TestRedirectSchema, TestRedirectPathWithFetch — existing integration tests still pass (legitimate redirects during handshake continue to work)
• Full go test ./plumbing/transport/http/... passes