building image with sha id in FROM

[rcerven]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

when building image with buildah with podman
and having in FROM sha of local image ID,
build fails

Steps to reproduce the issue:

1. create simple Dockerfile when in FROM you will specify sha of local image ID

2. build image : buildah bud

3. build will fail

$ buildah bud -t test ./
STEP 1: FROM sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e
error creating build container: The following failures happened while trying to pull image specified by "sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e" based on search registries in /etc/containers/registries.conf:

• "localhost/sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e": Error initializing source docker://localhost/sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
• "docker.io/library/sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e": Error initializing source docker://sha256:33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e: Error reading manifest 33df2983b06100d70b79fc667656a61bf2ca3978ff976a3db42de36f9b11192e in docker.io/library/sha256: errors:
  denied: requested access to the resource is denied
  unauthorized: authentication required

Describe the results you received:
build fails

Describe the results you expected:
having in FROM sha of local image ID is working with docker (docker/imagebuilder build with docker)

Output of podman version:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.14.9
Built:        Wed Sep 30 21:31:11 2020
OS/Arch:      linux/amd64

the same issue is in 2.2.0

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.19-1.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.19, commit: 5dce9767526ed27f177a8fa3f281889ad509fea7'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: journald
  hostname: dhcp-0-143.brq.redhat.com
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 2197152
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 2197152
      size: 65536
  kernel: 5.8.9-200.fc32.x86_64
  linkmode: dynamic
  memFree: 2317017088
  memTotal: 16178266112
  ociRuntime:
    name: crun
    package: crun-0.15-5.fc32.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.15
      commit: 56ca95e61639510c7dbd39ff512f80f626404969
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.4-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.4
      commit: b66ffa8e262507e37fca689822d23430f3357fe8
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 2
  swapFree: 8120168448
  swapTotal: 8120168448
  uptime: 1h 42m 22.2s (Approximately 0.04 days)
registries:
  brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888:
    Blocked: false
    Insecure: true
    Location: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888
    MirrorByDigestOnly: false
    Mirrors: []
    Prefix: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888
  brew-pulp-docker01.web.qa.ext.phx1.redhat.com:8888:
    Blocked: false
    Insecure: true
    Location: brew-pulp-docker01.web.qa.ext.phx1.redhat.com:8888
    MirrorByDigestOnly: false
    Mirrors: []
    Prefix: brew-pulp-docker01.web.qa.ext.phx1.redhat.com:8888
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888
  - brew-pulp-docker01.web.qa.ext.phx1.redhat.com:8888
store:
  configFile: /home/rcerven/.config/containers/storage.conf
  containerStore:
    number: 18
    paused: 0
    running: 1
    stopped: 17
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.2-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/rcerven/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 36
  runRoot: /run/user/1000
  volumePath: /home/rcerven/.local/share/containers/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 1601494271
  BuiltTime: Wed Sep 30 21:31:11 2020
  GitCommit: ""
  GoVersion: go1.14.9
  OsArch: linux/amd64
  Version: 2.1.1

Package info (e.g. output of rpm -q podman or apt list podman):

podman-2.1.1-7.fc32.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

No

Additional environment details (AWS, VirtualBox, physical, etc.):
physical with virtenv

[mheon]

@nalind @TomSweeneyRedHat PTAL

[nalind]

In this case the hex part of sha256:... is the image's ID and not the digest of its manifest.

I think fixing this in buildah is as easy as recognizing that form and internally stripping off the sha256: prefix, since it already knows how to look up images by ID.
We could probably do this in the lookup logic in the storage library to keep the behavior consistent across various tools.

I wasn't able to reproduce the error using a spot check with imagebuilder from its master branch. I'd pulled the image manually before that, though, since an image ID by itself isn't enough information for either docker or podman to be able to pull it from a registry. Were you testing with a different version?

[rcerven]

I have imagebuilder-0.0.6-1.el7eng.x86_64

but this issues seems to be problem with underlying podman,
because with underlying docker, docker/imagebuild works

[nalind]

Ah, so you're pointing imagebuilder at podman? That's an important detail, but it suggests that imagebuilder is correctly passing the name from the Dockerfile to the build API endpoint, so we're really just talking about podman.

[rcerven]

I've modified description (removed those docker/imagebuilder builds), this should be issue only about buildah build with podman

[rhatdan]

Since this is really a Buildah bug, I will move to Buildah, once fixed, there we can revendor into Podman

[rcerven]

Since this is really a Buildah bug, I will move to Buildah, once fixed, there we can revendor into Podman

ok

[TomSweeneyRedHat]

@vrothberg can you take a look at this one if you've a spare moment or three please?