podman pull output is missing digest information compared to docker

[candrews]

Issue Description

docker pull as provided by Docker outputs the digest of the image pulled. For example:

$ docker image pull debian:bullseye

bullseye: Pulling from library/debian
Digest: sha256:3f1d6c17773a45c97bd8f158d665c9709d7b29ed7917ac934086ad96f92e4510
Status: Downloaded newer image for debian:bullseye
docker.io/library/debian:bullseye

The output of the equivalent podman command is missing this information:

$ podman image pull debian:bullseye
Trying to pull docker.io/library/debian:bullseye...
Getting image source signatures
Copying blob 1e4aec178e08 skipped: already exists  
Copying config 54e726b437 done  
Writing manifest to image destination
Storing signatures
54e726b437fbb2dd7b43e4dd5cd79b0181e96a22849b7fc2ffe934fac2d65440

There are other ways to get the digest (such as by using podman inspect), but since it's so much easier to get the digest using docker, it would be nice to have parity with docker.

Steps to reproduce the issue

Steps to reproduce the issue

1. podman image pull debian:bullseye

Describe the results you received

$ podman image pull debian:bullseye
Trying to pull docker.io/library/debian:bullseye...
Getting image source signatures
Copying blob 1e4aec178e08 skipped: already exists  
Copying config 54e726b437 done  
Writing manifest to image destination
Storing signatures
54e726b437fbb2dd7b43e4dd5cd79b0181e96a22849b7fc2ffe934fac2d65440

Describe the results you expected

$ podman image pull debian:bullseye
Trying to pull docker.io/library/debian:bullseye...
Digest: sha256:3f1d6c17773a45c97bd8f158d665c9709d7b29ed7917ac934086ad96f92e4510
Getting image source signatures
Copying blob 1e4aec178e08 skipped: already exists  
Copying config 54e726b437 done  
Writing manifest to image destination
Storing signatures
54e726b437fbb2dd7b43e4dd5cd79b0181e96a22849b7fc2ffe934fac2d65440

podman info output

host:
  arch: amd64
  buildahVersion: 1.29.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.6-3.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.6, commit: '
  cpuUtilization:
    idlePercent: 94.57
    systemPercent: 1.65
    userPercent: 3.78
  cpus: 12
  distribution:
    distribution: fedora
    variant: workstation
    version: "37"
  eventLogger: journald
  hostname: craigworking
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.12-200.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 518524928
  memTotal: 16176816128
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.8-1.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8
      commit: 0356bf4aff9a133d655dc13b1d9ac9424706cac4
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-8.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 3080564736
  swapTotal: 8589930496
  uptime: 25h 24m 52.00s (Approximately 1.04 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/candrews/.config/containers/storage.conf
  containerStore:
    number: 587
    paused: 0
    running: 0
    stopped: 587
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/candrews/.local/share/containers/storage
  graphRootAllocated: 1022488477696
  graphRootUsed: 373104369664
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 267
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/candrews/.local/share/containers/storage/volumes
version:
  APIVersion: 4.4.1
  Built: 1676629579
  BuiltTime: Fri Feb 17 05:26:19 2023
  GitCommit: ""
  GoVersion: go1.19.5
  Os: linux
  OsArch: linux/amd64
  Version: 4.4.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

$ podman version
Client:       Podman Engine
Version:      4.4.1
API Version:  4.4.1
Go Version:   go1.19.5
Built:        Fri Feb 17 05:26:19 2023
OS/Arch:      linux/amd64
$ rpm -q podman
podman-4.4.1-3.fc37.x86_64

Additional information

No response

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

This seems reasonable @vrothberg WDYT?

[vrothberg]

Thanks for reaching out, @candrews !

This seems reasonable @vrothberg WDYT?

Yes, this sounds reasonable. In automation, podman inspect is the way to go but it seems like useful information when interacting with podman.

@mtrmac WDYT?

[mtrmac]

Note that the output already contains an image ID (config digest), which uniquely identifies the image. (OTOH it’s not the same thing as the manifest digest — it’s impossible to reconstruct the manifest digest that was pulled from the image ID if there are multiple matches.)

Could we discuss the use case first, please? After the image is pulled, it’s, in a sense, already too late to make any policy decisions; what’s done is done, why does the digest matter? Is this just to have the image identity recorded in logs for purpose of later investigation? The image ID should work for that — in a sense, better, because it deduplicates different representations.

Alternatively, if the goal is to ensure that “the right” digest is pulled, e.g. to consistently deploy exactly the same image to multiple systems, the commands should do just that — decide on a digest, maybe using skopeo inspect, and then issue a podman pull across the systems with a digest, not with a tag.

---

(copy.Image returns the manifest that was written to c/storage, which almost(?) always allows reporting the digest of the per-arch instance that was pulled. So that could be just printed. Alternatively, c/image might print the digest before starting the pull… by default, or with an opt-in.

But I’m tempted to think that it’s just clutter users don’t actually need at that point. Am I wrong?)

---

There’s also a question whether we should print the top-level multi-arch manifest digest (identifying what the tag points to), or the per-arch instance manifest digest (identifying which image variant was chosen, e.g. for ARM v6/v7…). Either could be possibly useful, but I don’t think we want both, at least in the default output.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Since we heard no feedback, I am closing. Reopen if you have feedback.

[vrothberg]

We don't need any more feedback for this one. I will reopen.

[vrothberg]

I see it (as the issue described) as a UX improvement (i.e., being much easier to see the digest directly).

[rhatdan]

Sadly no progress on this one.