Repository navigation
fix(installer): download verified archives with the identity encoding - #2064
Conversation
Node's fetch accepts gzip by default and dl.google.com then gzips the Go archive: Content-Length is the encoded size while fetch yields the decoded bytes, so every pinned Go download failed as truncated. download() now asks for the identity encoding, refuses an encoded response with a clear cause, and verifiedDownload keeps the transport error as its cause. A native Windows test downloads, verifies and runs the real pinned Go; the native gate counts 36. Closes #2063
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to The installer now requests unencoded archives, so the pinned Go download no longer fails on a length mismatch. Tests cover the new behavior, and I found no merge-blocking risk. Pre-merge checks |
|
Closes #2063
Root cause
Node's
fetchsendsAccept-Encoding: gzip, deflate, brby default. dl.google.com then serves the Go archive withContent-Encoding: gzipandContent-Length: 65267505(encoded), whilefetchdecodes to 67591780 bytes, sodownload()'s length check threwDownload truncatedandverifiedDownloadturned it into a bareDownload failed. Verified locally with Node's fetch (default vsaccept-encoding: identity) and on windows-latest (diag run 38092917737). The pinned Go was therefore never downloadable in production; tests used local adapters and CI used setup-go.What
download()requestsaccept-encoding: identity; an encoded response is refused withDownload was encoded (<enc>) although identity was requested; a non-OK status names the status.verifiedDownloadkeeps the transport error ascause.Tests
identity; a server that always encodes is refused with its cause; a failed transport keeps its cause.acquireGoagainst production dl.google.com on macOS published Go 1.25.14.Summary by CodeRabbit