Why did the hash for the golang:1.25.1-bookworm change?

[audunmo]

- FROM golang:1.25.1-bookworm@sha256:c4bc0741e3c79c0e2d47ca2505a06f5f2a44682ada94e1dba251a3854e60c2bd as builder-base
+ FROM golang:1.25.1-bookworm@sha256:c423747fbd96fd8f0b1102d947f51f9b266060217478e5f9bf86f145969562ee as builder-base

dependabot just opened the following PR against one the repos we have at work. What's going on here? This hash should've been stable no?

[audunmo]

Looking at both with dive, seems the only thing that has changed is the timestamp for the build.

The base layer is being built with debian.sh --arch 'arm54' out/ 'bookworm' <timestamp>

c42374 was built with timestamp @1759104000
c4bc07 was built with timestamp @1757289600

Why was this changed? And, if there are important updates here, shouldn't this have been separately versioned somehow?

[yosifkit]

Tags in the [official-images] are built through an update (like Dockerfile changes that may or may not include a version bump) or as a result of its base image being updated (ie, an image FROM debian:bookworm would be rebuilt when debian:bookworm is built).

We strive to publish updated images at least monthly for Debian. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Ubuntu, Alpine, and Oracle Linux, and are subject to their own maintenance schedule.

- https://github.com/docker-library/faq/blob/6e3dfac07af77b4a71c9d99e6ba1c47d2f972c0b/README.md#why-does-my-security-scanner-show-that-an-image-has-cves

The periodic Debian rebuild was triggered just a few days ago by docker-library/official-images#19982, so the Debian-based golang images were also rebuilt.

[audunmo]

I see. Is there any chance of versioning Debian separately from the Go version, a la the alpine images for example?

[yosifkit]

Is there any chance of versioning Debian separately from the Go version

We have no plans to do so beyond the OS release name (bookworm, trixie, etc). Our rebuilds when base images change have no influence on image tags. Luckily for the go image, the layer that contains the go binaries has been created deterministically and will not change even when the base image is updated (only when the go version changes).

For example, when looking at the layers of the amd64 images, this layer is in both images. And when digging in to just that layer, it is the go binaries.

{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"digest": "sha256:330457f0054be4c07fbaeac90483ac4f534113ccd944fe16beb9e079a3ab3a36",
"size": 60045609
},

[tianon]

FWIW, this is exactly the same level of granularity we support for Alpine (3.22, etc are essentially "major releases" of Alpine Linux - we don't tag for the minor releases like 3.22.1, etc)