Download hop 2 follows redirects in four SDKs: needs a cross-SDK destination policy, not a Go patch

[jeremy]

fetchSignedDownload (go/pkg/basecamp/download.go:16) builds its own *http.Client and sets no CheckRedirect, so the unauthenticated second hop of a download follows up to 10 redirects under net/http's default policy — cross-host, unbounded in destination.

Every other hop in the SDK that can be steered by a response suppresses redirects. fetchAPIDownload's authenticated hop sets http.ErrUseLastResponse twelve lines above this one; OAuth discovery does the same, and SPEC.md §16 requirement 3 names it as a hardening requirement. This hop is the exception, and it looks unintentional rather than argued — there is no comment either way, where the neighbouring decisions are all commented.

Reproduced with a throwaway test: an API host 302s to a "signed" host, which redirects 9 times and lands on a third server. The SDK followed the whole chain and returned the third server's body:

RESULT body="SECRET" signedHops=9 finalHits=1

The reach is narrower than SSRF: the first Location comes from the operator-configured API host, so the chain starts somewhere trusted, and no credentials are attached on this hop (TestDownload_SecondLegNoAuth). What is unbounded is where it ends up — a compromised or misconfigured object store decides that, and the caller receives the final body as if it were the requested file.

Not filed as part of it: the Timeout: 0 on the same client. That one is deliberate, commented (streaming owned by caller), and pinned by TestDownload_SecondLegNoTimeout. It should stay.

Not fixed here on purpose. The remedy is a product call, not a mechanical one, and it needs someone who knows what the fleet's storage backends actually do:

• Suppress outright (ErrUseLastResponse), matching every sibling hop — but S3 region redirects and CloudFront chains are real, so this may break live downloads.
• Cap the chain (1–2 hops) and re-validate each target, keeping the common case working.
• Leave it and write down why, so the next reader does not re-open this.

Happy to implement whichever, once the object-store behaviour is settled. Filed separately from #804 by design — no dependency either way.

[jeremy]

Reframing: this is a cross-SDK/spec decision, not a Go patch

Filed as a Go-only finding. That framing is wrong, and patching Go alone would be the worst available outcome — it would close one spelling of the behavior, leave three open, and make the fleet look hardened.

Hop 2 follows redirects in four of the SDKs, each by a different mechanism, which is why no single-language fix generalizes:

SDK	Hop-2 call site	How redirects are followed	Cap
Go	fetchSignedDownload	no CheckRedirect set → net/http default	10
Python	download.py:122,134 _fetch_signed / _fetch_signed_async	follow_redirects=True written explicitly	httpx default
TypeScript	download.ts:242 fetch(resolvedLocation)	bare fetch, no redirect option → defaults to "follow"	20
Swift	HTTPClient.swift:500 fetchSignedDownload → transport.data(for:)	redirect-following transport, not dataWithoutRedirects	URLSession default

Ruby has no download-URL path, so the surface is four, not five.

Python is the one that settles the framing. Every other client in that SDK sets follow_redirects=False — _transport.py:157, _async_http.py:45, _http.py:44 — and the download path sets it to True on purpose. So this is not four copies of one oversight; at least one SDK made a deliberate choice, and that choice needs to be either ratified or reversed as a specification, not silently diverged from by whichever language gets patched first.

TypeScript and Swift are the mirror image: both take hop 1's redirect manually (redirect: "manual", dataWithoutRedirects) and then hand hop 2 to a following default. The care taken on hop 1 makes the hop-2 default look accidental rather than chosen.

The decision, and what each option actually buys

1. If production storage never redirects on the signed URL — suppress hop-2 redirects in all four SDKs. Cheapest, strongest, and the only option that closes destination steering outright.
2. If redirects are required (multi-region object stores, CDN edge indirection) — specify an exact hop limit and a destination policy, uniformly. The destination policy is the load-bearing half.
3. A hop cap alone is not a fix. It bounds loops and resource exhaustion. It does nothing about destination steering: one redirect to an internal address is under every cap being discussed.

Why this stays open and non-blocking

The remedy depends on evidence nobody in this thread has: whether the fleet's object stores actually redirect. Guessing wrong in either direction is bad — suppress when redirects are load-bearing and downloads break in production; cap-only and we ship a control that does not address the risk while reading as though it does.

So: keep open, non-blocking, pending that fleet evidence. It does not gate #804, which covers a different hop with a different threat model (an advertised issuer from a parsed response body, versus a Location minted by the operator-configured API host).

Once someone can say what the storage tier does, the fix is small in all four languages and should land as one spec change plus four implementations in the same commit, per the repo's existing cross-SDK convention.