backup: Bump gocloud.dev to v0.47.0 for S3-compatible backup sink
What does this MR do?
Bumps gocloud.dev from v0.46.0 to v0.47.0 (and transitive AWS SDK
deps) to fix server-side repository backups against stricter
S3-compatible object stores.
Why
The server-side backup sink uploads via gocloud.dev/blob/s3blob. In
v0.46.0 the s3blob writer set RequestChecksumCalculation on the S3
client but not on the transfermanager.Client it created. The
transfer manager's own setting wins and defaults to WhenSupported,
so request_checksum_calculation=when_required never reached the
upload-signing code. Every PutObject went out with SDK v2's streaming
checksum format (x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER
Content-Encoding: aws-chunked), which some S3-compatible stores (e.g. Dell ECS) reject with HTTP 400XAmzContentSHA256Mismatch.
Regression background
This was a regression introduced in gocloud v0.46.0 and affects only that release:
- The integrity-protection setting was added in gocloud v0.44.0. In
v0.44.0 and v0.45.0 the s3blob writer used the
s3/manageruploader and carriedRequestChecksumCalculationonto it, sowhen_requiredworked (plainx-amz-content-sha256: UNSIGNED-PAYLOAD). - v0.46.0 migrated from
s3/managertos3/transfermanager(google/go-cloud#3717). The newtransfermanager.New(...)was configured with part size and concurrency only; theRequestChecksumCalculationassignment was dropped, so the transfer manager silently fell back to itsWhenSupporteddefault. - v0.47.0 restores it (google/go-cloud#3766), threading the setting into the transfer manager's own options.
GitLab 19.5.1 pins exactly gocloud v0.46.0, the one affected release.
Upstream fix: https://github.com/google/go-cloud/pull/3766
No Gitaly configuration change is required. Gitaly already injects
request_checksum_calculation=when_required by default for
endpoint-based URLs via withS3DefaultChecksumCalculation.
Verification
- `go build ./...` passes.
- Reported in https://gitlab.com/gitlab-com/request-for-help/-/work_items/5649