Hash a forwarded image's uncompressed stream, not its gzip file #40
No reviewers
Labels
No labels
⏳in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Grey.ooo/someones.computer_agent!40
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/forwarded-image-uncompressed-hash"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hash a forwarded image's uncompressed stream, not its gzip file
dockercli.Save wrote the docker-save tarball through gzip and then hashed
the compressed .tar.gz on disk. The platform's ImageStorage/GzipTarHasher
verifies against the sha256 of the decompressed stream (the same rule
build contexts already follow), so every client-forwarded image failed
upload with "image sha256 mismatch" regardless of the image's actual
content.
Save now tees the docker-save stream through both gzip and a sha256 hasher
via io.MultiWriter and returns that hash directly, so the manifest and the
uploaded bytes are computed from the same source. forward.go's separate
sha256File (which hashed the gzip file) is gone with it.
Bumps the dockercli coverage floor from 91.7% to 90.0%: the new
"gzip.Close() failed" branch mirrors the existing waitErr/copyErr checks
but isn't practically triggerable from a test without a broken writer.
Duplicate of #39, which already has an equivalent (cleaner — single-pass hash, and handles the gzip.Close() coverage gap properly instead of bumping the floor) fix and is green. Closing this one in favour of #39.
Pull request closed