imagecat.Fetch and kernelcat.Fetch each implement the same pattern:
HTTP GET with a Content-Length pre-check, an io.LimitReader cap on
the body, on-the-fly sha256 hashing, and refusal on either the cap
trip or a hash mismatch. The about-to-arrive `banger update` flow
makes a third caller, which is the right number to factor.
* internal/download.FetchVerified(ctx, client, url, expectedSHA256,
maxBytes, dstPath): streams the body to dstPath through a
sha256 hasher, capped at maxBytes+1 bytes so an oversize body
is detected before the hash check fires. On any failure
(HTTP error, ContentLength > cap, body exceeds cap, write
error, hash mismatch) the partial file is removed before
returning so callers don't have to disambiguate "did we leave
bytes on disk?".
Imagecat and kernelcat are NOT migrated to this helper in this
commit — they each have their own destination-dir layout and
post-verify decompress/extract steps that don't fit a one-size
helper. Lift them later if it stays clean; for now the helper
is sized for the updater's "fetch tarball + sha256SUMS" need.
Tests cover happy path, hash mismatch, advertised Content-Length
over cap, lying server (chunked, no Content-Length, but oversize
body), HTTP non-2xx, and the two arg-validation rejections (empty
expected hash, non-positive maxBytes).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Thales Maciel
abd5d6f5ab