can't tag a image with digest: refusing to create a tag with a digest reference

[TownTowner]

Description

When you do that, you get an error: refusing to create a tag with a digest reference

cmd:
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.3 registry.k8s.io/metrics-server/metrics-server:v0.6.3@sha256:c60778fa1c44d0c5a0c4530ebe83f9243ee6fc02f4c3dc59226c201931350b10

I can pull with a digest, but can't tag it with a digest.

Why? Or I missed something?

Reproduce

1. docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.3@sha256:c60778fa1c44d0c5a0c4530ebe83f9243ee6fc02f4c3dc59226c201931350b10
2. docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.3 registry.k8s.io/metrics-server/metrics-server:v0.6.3@sha256:c60778fa1c44d0c5a0c4530ebe83f9243ee6fc02f4c3dc59226c201931350b10

Expected behavior

Usage: docker tag SOURCE_IMAGE[:TAG]:[DIGEST] TARGET_IMAGE[:TAG]:[DIGEST]

Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE

docker version

Client:
 Cloud integration: v1.0.35-desktop+001
 Version:           24.0.5
 API version:       1.43
 Go version:        go1.20.6
 Git commit:        ced0996
 Built:             Fri Jul 21 20:36:24 2023
 OS/Arch:           windows/amd64
 Context:           default

Server: Docker Desktop 4.22.0 (117440)
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.6
  Git commit:       a61e2b4
  Built:            Fri Jul 21 20:35:45 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.21
  GitCommit:        3dce8eb055cbb6872793272b4f20ed16117344f8
 runc:
  Version:          1.1.7
  GitCommit:        v1.1.7-0-g860f061
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    24.0.5
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.20.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.20
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v0.1.0-beta.6
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scan: Docker Scan (Docker Inc.)
    Version:  v0.26.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scan.exe
  scout: Command line tool for Docker Scout (Docker Inc.)
    Version:  0.20.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 22
  Running: 4
  Paused: 0
  Stopped: 18
 Images: 27
 Server Version: 24.0.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
 runc version: v1.1.7-0-g860f061
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.90.1-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 5.791GiB
 Name: docker-desktop
 ID: aeee4333-6160-4e19-8c1e-a5f59a91d929
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Registry Mirrors:
  https://registry.docker-cn.com/
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile

Additional Info

No response

[juanmirocks]

Similar problem here.
I docker pull an image with a tag & digest. Pulling the image works, but it ends up without a tag (<none>).
Is this expected?

My stack:

• Docker version: 24.0.7
• Docker Desktop: 4.26.1

[thaJeztah]

I can pull with a digest, but can't tag it with a digest.

That's expected. The digest is calculated over the content, and a user should not be able to manually set the digest, as that would mean I could manually "fake" the digest. We could technically ignore the digest in that case (consider image:tag@digest to be equivalent of image:tag and ignore the digest), but this would be even more confusing.

I docker pull an image with a tag & digest. Pulling the image works, but it ends up without a tag ().
Is this expected?

Yes, that's currently expected; the image:tag@digest format was originally created for swarm services that "pin" to a digest. The :tag was added to allow presenting "this was the tag that was specified, and this was the digest that was resolved for it" . When pulling an image using both tag and digest, the tag is not used to resolve the image, but the image is pulled "by digest". In that case, no tag is created (as it was not used to resolve the image), and only the digest is present.

I'll close this ticket, because there's no bug at hand, but feel free to continue the conversation.

[juanmirocks]

Thank you @thaJeztah for the contextual information. I see your point and I understand this is the currently expected behavior.

My 2 cents:

• If I try to pull image:tag@digest, BOTH the tag & the digest should be resolved. If they end up pointing to a different image, that should throw an error. Otherwise, if the tag is completely ignored, why allow it at all to be together with a digest ?
• If both point to the same image, pull it, and tag it accordingly.

[lemuelroberto]

For those who just want a straightforward fix, run docker buildx prune -f to remove all build cache.