Unexpected behavior using duplicate layer name in multistaged build

[p-fruck]

Description

Assume I have three stages in a multistaged build, where 2 copies from 1 and 3 copies from 2. Furthermore, I mistakenly gave layer 2 and 3 the same name. Copying a file from the first layer into the second results in the following message when using upper case names: no stage or image found with that name. This is not quiet correct, rather the second layer name is used twice. But when I change the first layer name to lower case, buildah suddenly tries to pull the image from a remote registry, which should probably not happen.

Steps to reproduce the issue:

1. Create the following Containerfile:

FROM alpine:latest as FIRST
RUN echo 1 > /tmp/file

FROM alpine:latest as SECOND
COPY --from=FIRST /tmp/file /tmp/file

FROM alpine:latest as SECOND # should be named THIRD
COPY --from=SECOND /tmp/file /tmp/file

2. Run buildah bud and receive the following message:

[2/3] STEP 1/2: FROM alpine:latest AS SECOND
[2/3] STEP 2/2: COPY --from=FIRST /tmp/file .
Error: COPY --from=FIRST: no stage or image found with that name

3. Run the following command to retry with a lowercase name and see the image being pulled from a remote registry: sed -i 's/FIRST/first/g' Containerfile && buildah bud

[2/3] STEP 1/2: FROM alpine:latest AS SECOND
[2/3] STEP 2/2: COPY --from=first /tmp/file .
? Please select an image: 
  ▸ registry.fedoraproject.org/first:latest
    registry.access.redhat.com/first:latest
    docker.io/library/first:latest
    quay.io/first:latest

Describe the results you received: shown above

Describe the results you expected: should either build successfully or show an error message, e.g. duplicate layer name

Output of rpm -q buildah or apt list buildah:

buildah-1.32.2-1.fc39.x86_64

Output of buildah version:

Version:         1.32.2
Go Version:      go1.21.1
Image Spec:      1.1.0-rc.4
Runtime Spec:    1.1.0
CNI Spec:        1.0.0
libcni Version:  
image Version:   5.28.0
Git Commit:      
Built:           Tue Oct 31 09:39:32 2023
OS/Arch:         linux/amd64
BuildPlatform:   linux/amd64

Output of podman version if reporting a podman build issue:

Client:       Podman Engine
Version:      4.7.2
API Version:  4.7.2
Go Version:   go1.21.1
Built:        Tue Oct 31 15:32:01 2023
OS/Arch:      linux/amd64

Output of cat /etc/*release:

Fedora release 39 (Thirty Nine)
NAME="Fedora Linux"
VERSION="39.20231114.0 (Silverblue)"
ID=fedora
VERSION_ID=39
VERSION_CODENAME=""
PLATFORM_ID="platform:f39"
PRETTY_NAME="Fedora Linux 39.20231114.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:39"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://silverblue.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://github.com/fedora-silverblue/issue-tracker/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=39
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=39
SUPPORT_END=2024-05-14
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='39.20231114.0'
Fedora release 39 (Thirty Nine)
Fedora release 39 (Thirty Nine)

Output of uname -a:

Linux spectre 6.5.11-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov  8 22:37:57 UTC 2023 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

cat: /etc/containers/storage.conf: No such file or directory

[flouthoc]

I'll check this thanks.