Misleading „push date“ instead of build date, useless digest identifier

[hadmut]

Hi,

on many docker hub pages, such as

https://hub.docker.com/search?q=rabbitmq
https://hub.docker.com/_/rabbitmq
https://hub.docker.com/_/rabbitmq/tags

(same with other projects, e.g. ruby )

just the date of last push is given, which wrongly makes images appear as somewhat fresh or new, e.g.

TAG
4.0-management

Last pushed 3 days by doijanky

where in fact the image is stoneage old:

docker pull rabbitmq:4.0-management

4.0-management: Pulling from library/rabbitmq
4b3ffd8ccb52: Pull complete
883958f9d92b: Pull complete
f860d4e2d5bc: Pull complete
96aedc9464ed: Pull complete
753f597d0f33: Pull complete
1cd0a4c43107: Pull complete
3b2069fd77a3: Pull complete
2614367bcc3f: Pull complete
e200531438bf: Pull complete
5ebe8ca8bf0e: Pull complete
Digest: sha256:438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95
Status: Downloaded newer image for rabbitmq:4.0-management
docker.io/library/rabbitmq:4.0-management

docker image list rabbitmq:4.0-management

REPOSITORY TAG IMAGE ID CREATED SIZE
rabbitmq 4.0-management 5e283cfbf5e6 13 months ago 264MB

docker image inspect rabbitmq:4.0-management

...
"Id": "sha256:5e283cfbf5e6db90ac32eec5f8ef574eca3096b474cf29ee4f7eb2b0b89d4a17",
"RepoTags": [
"rabbitmq:4.0-management"
],
"RepoDigests": [
"rabbitmq@sha256:438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95"
],
...
"Created": "2024-09-20T21:15:09Z",

This image is over a year old.

It is also confusing to list an image on docker hub as

Digest OS/ARCH
Vulnerabilities
Compressed size

45ab3ffe0ed9
linux/amd64

when this digest never appears in

docker image inspect rabbitmq:4.0-management | fgrep -i 45ab

You need to follow the link and look for the index-digest on
https://hub.docker.com/layers/library/rabbitmq/4.0-management/images/sha256-45ab3ffe0ed9a89beb23d8776c83d2e493209f627edba76153790a859c221cf3
which is
438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95

docker image inspect rabbitmq:4.0-management | fgrep -i 438c

        "rabbitmq@sha256:438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95"

What's the point in displaying a DIGEST, that the user can't verify or identify?

Both problems are security relevant

• The useless DIGEST makes it impossible (difficult, cumbersome) to verify, that the local copy is identical with the version on the hub.
• Showing a date like "Last pushed 3 days" makes it look fresh, while it actually is 13 months old and can make users wrongly believe that recent security gaps have been fixed.

[github-actions]

Thank you for your feedback 👍.

Our team will review your issue shortly.
In the meantime, feel free to provide as many details as possible, as this will speed up the resolution.

If you need assistance rather than providing feedback, please contact the Docker support team via https://www.docker.com/support/ for a prompt response, and close this issue.

[tianon]

There are several things here that I could tackle trying to explain better, but I think docker-library/httpd#266 (comment) gets at the root of the biggest one:

We set SOURCE_DATE_EPOCH (buildkit docs) while building -- if you want to see the date the build was performed, you'll want to look at the org.opencontainers.image.created annotation we add in the image index (relevant code) instead: https://oci.dag.dev/?image=httpd:2.4-alpine ("org.opencontainers.image.created": "2024-09-06T23:20:57Z").

If we look at https://oci.dag.dev/?image=rabbitmq:4.0-management (which shows us the actual raw image data stored in the registry), we can see "org.opencontainers.image.created": "2025-10-09T22:18:55Z" (and similar dates/times for all the images in this index), which is when these builds were actually completed.

As for verifying the local image is the same as the remote image, actually doing that effectively requires enabling the containerd integration in the Docker Engine such that the original content from the registry persists and can be verified.

To illustrate, here's some example commands using the crane CLI tool to fetch the raw registry objects to show what those digests mean:

$ crane digest rabbitmq:4.0-management
sha256:438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95
$ crane manifest rabbitmq:4.0-management | sha256sum
438c232a3a39d091645c5ac2b382c9f46c1ff3f1230587c0f20c5f1f7b6a6c95  -
$ crane manifest rabbitmq:4.0-management | jq '.manifests[] | select(.platform.os == "linux" and .platform.architecture == "amd64")'
{
  "annotations": {
    "com.docker.official-images.bashbrew.arch": "amd64",
    "org.opencontainers.image.base.digest": "sha256:d3c6f195120fcbdcc9373fac4783f006f2a4c55a285df52a4c9d03299006fdbd",
    "org.opencontainers.image.base.name": "rabbitmq:4.0",
    "org.opencontainers.image.created": "2025-10-09T22:18:55Z",
    "org.opencontainers.image.revision": "36e4d246e934a96b1c3a920e398f96434f3fc34c",
    "org.opencontainers.image.source": "https://github.com/docker-library/rabbitmq.git#36e4d246e934a96b1c3a920e398f96434f3fc34c:4.0/ubuntu/management",
    "org.opencontainers.image.url": "https://hub.docker.com/_/rabbitmq",
    "org.opencontainers.image.version": "4.0.9-management"
  },
  "digest": "sha256:45ab3ffe0ed9a89beb23d8776c83d2e493209f627edba76153790a859c221cf3",
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "platform": {
    "architecture": "amd64",
    "os": "linux"
  },
  "size": 2885
}
$ crane manifest rabbitmq@sha256:45ab3ffe0ed9a89beb23d8776c83d2e493209f627edba76153790a859c221cf3 | sha256sum
45ab3ffe0ed9a89beb23d8776c83d2e493209f627edba76153790a859c221cf3  -
$ crane config rabbitmq@sha256:45ab3ffe0ed9a89beb23d8776c83d2e493209f627edba76153790a859c221cf3 | jq '.created'
"2024-09-20T21:15:09Z"
$ # ^ this is that "SOURCE_DATE_EPOCH" value that you're seeing in the "docker images" metadata

[tianon]

(this should be closed, but I don't have any permissions here; I've filed a related PR at docker-library/meta-scripts#135, but this should be closed with or without it and if we need more conversation it can happen on the closed issue ❤️)