chore(deps): github.com/docker/buildx v0.36.0-rc2, buildkit v0.32.0-rc2

[glours]

What I did
Test the upcoming buildx and BuildKit releases ahead of GA. buildx v0.36.0-rc2 requires Go >= 1.26.3, so the go directive moves from 1.25.9 to 1.26.3.

Related issue
N/A

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[docker-agent]

Assessment: 🟢 APPROVE

This PR bumps github.com/docker/buildx to v0.36.0-rc2, github.com/moby/buildkit to v0.32.0-rc2, and advances the go directive from 1.25.9 to 1.26.3. The changes to go.mod and go.sum are mechanically consistent with the dependency upgrades — updated direct deps, new/updated transitives, and matching hash entries in go.sum. No bugs were identified in the introduced changes.

[thaJeztah]

Failure looks consistent; could be changes in containerd code? Or is it a test-registry not accepting some content?

url="http://localhost:32768/v2/test/manifests/sha256:492f68f4767a11b76825698c289e3519ba52bfeb04b0c95fe7e9f12422ce957d"
        time="2026-07-28T08:22:08Z" level=debug msg="fetch response received" host="localhost:32768" method=HEAD response.header.content-length=122 response.header.content-type=application/json response.header.date="Tue, 28 Jul 2026 08:22:08 GMT" response.header.docker-distribution-api-version=registry/2.0 response.status="500 Internal Server Error" spanID=b3a91e5b2268295f traceID=e3137962f4fbc1ba30eb878a2c86e732 url="http://localhost:32768/v2/test/manifests/sha256:492f68f4767a11b76825698c289e3519ba52bfeb04b0c95fe7e9f12422ce957d"
        time="2026-07-28T08:22:08Z" level=info msg="fetch failed after status: 500 Internal Server Error" host="localhost:32768" method=HEAD spanID=b3a91e5b2268295f traceID=e3137962f4fbc1ba30eb878a2c86e732 url="http://localhost:32768/v2/test/manifests/sha256:492f68f4767a11b76825698c289e3519ba52bfeb04b0c95fe7e9f12422ce957d"
        unexpected status from HEAD request to http://localhost:32768/v2/test/manifests/sha256:492f68f4767a11b76825698c289e3519ba52bfeb04b0c95fe7e9f12422ce957d: 500 Internal Server Error
        
        
        Failures:
        ExitCode was 1 expected 0
        Expected no error
    publish_test.go:166: 	[TestPublish] docker rm --force compose-e2e-publish-registry

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

Both findings are in the newly introduced GetBlob function in internal/oci/resolver.go. The dependency bumps and refactoring in pullComposeFiles are otherwise correct and well-structured. The blob-endpoint approach is the right fix for the manifests-vs-blobs endpoint confusion described in the PR.

[codecov]

Codecov Report

❌ Patch coverage is 57.89474% with 8 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/oci/resolver.go	55.55%	4 Missing and 4 partials ⚠️

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟡 NEEDS ATTENTION

Dismissed security findings (review manually)

• internal/oci/resolver.go:115 — Integer overflow in io.LimitReader when descriptor.Size is math.MaxInt64 (verifier mitigation: overflow produces 0-byte read, and the size-mismatch check at line 119 immediately returns an error — no silent bypass; impact is at most an unexpected error, not data corruption)

[docker-agent]

Assessment: 🟢 APPROVE

The PR is a routine dependency bump (buildx v0.36.0-rc2, BuildKit v0.32.0-rc2, Go 1.25.9→1.26.3) plus a new GetBlob helper in internal/oci/resolver.go that fetches artifact layers directly from the blobs endpoint. The dependency changes look correct and the new function is well-structured with size-bounding and digest verification. One low-severity edge case was found.

[docker-agent]

[low] Integer overflow in LimitReader bound when descriptor.Size == math.MaxInt64

descriptor.Size+1 overflows to math.MinInt64 when descriptor.Size is math.MaxInt64. io.LimitReader with a negative limit reads 0 bytes immediately, so the size mismatch check fires and the error message says "got 0 bytes" instead of OOM — but the OOM guard intent is defeated for any descriptor claiming exactly math.MaxInt64 bytes. A safe fix caps the limit before adding 1:

Suggested change

	content, err := io.ReadAll(io.LimitReader(fetch, descriptor.Size+1))
	limit := descriptor.Size
	if limit < math.MaxInt64 {
	limit++
	}
	content, err := io.ReadAll(io.LimitReader(fetch, limit))

Confidence	Score
🟢 strong	100/100