Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman farm build cannot handle colons in the --tag value #25039

Open
tangentsoft opened this issue Jan 17, 2025 · 3 comments
Open

podman farm build cannot handle colons in the --tag value #25039

tangentsoft opened this issue Jan 17, 2025 · 3 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@tangentsoft
Copy link
Contributor

Issue Description

The relevant docs claim you can give an optional [:tag] with this option to override the default :latest, but if you do, you get the bogus error output below.

This is not limited to version tags, however. The same thing also occurs when you give a nonstandard registry TCP port number in the tag, as when pushing to a local Distribution instance, when it isn't listening on 5000 for whatever reason.

It is my belief that there is something doing a string split on colons and treating everything to the left as a URI scheme even though one does not normally prepend https:// to a --tag value.

Steps to reproduce the issue

Clone the PodmanHello repo, then apply this one-line patch:

diff --git a/Makefile b/Makefile
index 78910a7..537cac6 100644
--- a/Makefile
+++ b/Makefile
@@ -7,7 +7,7 @@ LDFLAGS = -static
 .PHONY: build run
 
 build:
-	$(PODMAN) build -t $(IMAGE) .
+	$(PODMAN) farm build -t registry:12345/repo/$(IMAGE):custom .
 
 run:
 	$(PODMAN) run $(IMAGE)

Now say make.

It is not important to set up a "farm" before doing this. The default one will show the symptom, as will a custom one.

It is also not important to give a real registry reference in the value above. You can leave it as given above and it will show the symptom because the error occurs before the actual TCP connection or registry login steps.

If you remove the ":12345" bit, you will see that the error you get changes accordingly, now split on the colon before custom.

Changing the --tag value to something colon-free like quay.io/USER/REPO will allow the push to succeed.

Describe the results you received

Error: build: building: 2 errors occurred:
	* pushing image {"85eb3be3087bc53bb17d96cd56b4cab5a5b52dfe14f8d72558b83f075211ff78" "oci-archive"} to registry: Invalid image name "registry:12345/repo/myhello:custom@@unknown-digest@@", unknown transport "registry"
	* pushing image {"40fb5173ffb64f7c3445a0b75773620532354ad6867a7f8beb7668ba7fe8f5cc" "oci-archive"} to registry: Invalid image name "registry:12345/repo/myhello:custom@@unknown-digest@@", unknown transport "registry"

Describe the results you expected

It should attempt to connect to registry:12345 and push the successfully-built image to the "repo" repository.

podman info output

host:
  arch: arm64
  buildahVersion: 1.38.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.12-3.fc41.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: '
  cpuUtilization:
    idlePercent: 96.56
    systemPercent: 0.82
    userPercent: 2.63
  cpus: 10
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: silverblue
    version: "41"
  eventLogger: journald
  freeLocks: 2047
  hostname: develi
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.12.8-200.fc41.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 3895042048
  memTotal: 8294932480
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.13.1-1.fc41.aarch64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.13.1
    package: netavark-1.13.1-1.fc41.aarch64
    path: /usr/libexec/podman/netavark
    version: netavark 1.13.1
  ociRuntime:
    name: crun
    package: crun-1.19.1-1.fc41.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.19.1
      commit: 3e32a70c93f5aa5fea69b50256cca7fd4aa23c80
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20241211.g09478d5-1.fc41.aarch64
    version: |
      pasta 0^20241211.g09478d5-1.fc41.aarch64-pasta
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  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,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-1.fc41.aarch64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.5
  swapFree: 8294232064
  swapTotal: 8294232064
  uptime: 0h 51m 13.00s
  variant: v8
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: $HOME/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: $HOME/.local/share/containers/storage
  graphRootAllocated: 67014492160
  graphRootUsed: 16879116288
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 126
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: $HOME/.local/share/containers/storage/volumes
version:
  APIVersion: 5.3.1
  Built: 1732147200
  BuiltTime: Wed Nov 20 17:00:00 2024
  GitCommit: ""
  GoVersion: go1.23.3
  Os: linux
  OsArch: linux/arm64
  Version: 5.3.1

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

I do not believe the "info" output above to include critical details. It happens to show a build using 5.3.1 on Silverblue, but I've seen this occur with 5.2.2 on EL9 as well.

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

@tangentsoft tangentsoft added the kind/bug Categorizes issue or PR as related to a bug. label Jan 17, 2025
@afbjorklund
Copy link
Contributor

There was some kind of parsing added, that allowed podman farm build --tls-verify=false -t localhost:5000/myimage

It still fails if you try to tag the image with something other than "latest", though. Or even if you add :latest yourself.

Invalid image name "localhost:5000/mybuild:latest@@unknown-digest@@", unknown transport "localhost"

@tangentsoft
Copy link
Contributor Author

Hopefully the TLS thing is orthogonal, since our local Distribution registries use certs to protect the login.

@afbjorklund
Copy link
Contributor

afbjorklund commented Jan 18, 2025

Hopefully the TLS thing is orthogonal, since our local Distribution registries use certs to protect the login.

It is, it just depends on how your registry is configured... By default it runs HTTP, unless you give it certs.

https://distribution.github.io/distribution/about/deploying/

http: server gave HTTP response to HTTPS client

Podman doesn't configure localhost to be insecure by default, like Docker does, so it needs registries.conf

[[registry]]
location="localhost:5000"
insecure=true

Problem was that podman farm didn't read the registries.conf either, so it needed that explicit parameter.

If you build and tag and push the image normally, then it works just fine. But farm is a different code path...

commit a06685a (5.0, not backported to 4.9)

Beyond the local testing, then it needs to be configured with certs and insecure is not needed anymore:

https://distribution.github.io/distribution/about/deploying/#run-an-externally-accessible-registry


This bug here is more about the tag ("latest") conflicting with the @@unknown-digest@@ added

And if you just remove that part from the code, then it gets into similar trouble further down

                       report, err := engine.Push(ctx, image.ID, l.listName+docker.UnknownDigestSuffix, entities.ImagePushOptions{Authfile: l.options.authfile, Quiet: false, SkipTLSVerify: skipTLSVerify})

So it needs to handle the tag properly, first add all the images to the manifest and then tag it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

2 participants