Container registry lists the architecture unknown/unknown when manifest attestations are present #10927

Closed
opened 2025-11-02 09:22:23 -06:00 by GiteaMirror · 4 comments
Owner

Originally created by @KN4CK3R on GitHub (May 28, 2023).

Related:
https://github.com/orgs/community/discussions/45969
https://github.com/docker/build-push-action/issues/755
https://codeberg.org/forgejo/forgejo/issues/780

I recently noticed that packages that have been pushed to the container registry using docker buildx build now have a new architecture listed, unknown/unknown. After some further investigation, I discovered that what is happening is that the Docker Buildx CLI is including image attestations for these images, which seems harmless, but causes GitHub Packages to list the unknown/unknown arch used for these attestations under the "OS / Arch" tab. This is similar to another topic recently posted, but this is more of a UI bug rather than an issue inspecting or pulling the manifests.

The current behavior means that if you push an image for linux/arm64 and linux/amd64, you'll get three architectures listed, linux/arm64, linux/amd64, and unknown/unknown. The unknown/unknown arch has a hash listed, but that is not shown in the version list anywhere unless you dig deep to find it. This appears to inconsistent with what the Docker Hub shows, which, in this case, would be only two architectures linux/arm64 and linux/amd64.

Originally created by @KN4CK3R on GitHub (May 28, 2023). Related: https://github.com/orgs/community/discussions/45969 https://github.com/docker/build-push-action/issues/755 https://codeberg.org/forgejo/forgejo/issues/780 > I recently noticed that packages that have been pushed to the container registry using `docker buildx build` now have a new architecture listed, `unknown/unknown`. After some further investigation, I discovered that what is happening is that the Docker Buildx CLI is including image attestations for these images, which seems harmless, but causes GitHub Packages to list the `unknown/unknown` arch used for these attestations under the "OS / Arch" tab. This is similar to another topic recently posted, but this is more of a UI bug rather than an issue inspecting or pulling the manifests. > > The current behavior means that if you push an image for `linux/arm64` and `linux/amd64`, you'll get three architectures listed, `linux/arm64`, `linux/amd64`, and `unknown/unknown`. The `unknown/unknown` arch has a hash listed, but that is not shown in the version list anywhere unless you dig deep to find it. This appears to inconsistent with what the Docker Hub shows, which, in this case, would be only two architectures `linux/arm64` and `linux/amd64`.
GiteaMirror added the topic/packagestype/bug labels 2025-11-02 09:22:23 -06:00
Author
Owner

@the-hotmann commented on GitHub (Nov 29, 2024):

Same problem here - this confused me quite a bit.
Can someone please check why exactly this is happening and is this something that is wanted?

@the-hotmann commented on GitHub (Nov 29, 2024): Same problem here - this confused me quite a bit. Can someone please check why exactly this is happening and is this something that is wanted?
Author
Owner

@hiifong commented on GitHub (Nov 30, 2024):

@KN4CK3R @the-hotmann Can you try this command?

docker buildx create --use --name {image}
docker buildx build --platform linux/amd64,linux/arm64 -t {gitea.domain}/{owner}/{image}:latest . --push --provenance false
@hiifong commented on GitHub (Nov 30, 2024): @KN4CK3R @the-hotmann Can you try [this command](https://github.com/go-gitea/gitea/issues/32170#issuecomment-2491269071)? ```shell docker buildx create --use --name {image} docker buildx build --platform linux/amd64,linux/arm64 -t {gitea.domain}/{owner}/{image}:latest . --push --provenance false ```
Author
Owner

@the-hotmann commented on GitHub (Dec 1, 2024):

Hi @hiifong,

thanks. Adding --provenance false to the docker buildx-command did the trick.
I wonder what the downsides of this are?

@the-hotmann commented on GitHub (Dec 1, 2024): Hi @hiifong, thanks. Adding `--provenance false` to the `docker buildx`-command did the trick. I wonder what the downsides of this are?
Author
Owner

@the-hotmann commented on GitHub (Dec 1, 2024):

Also deleting single "layers" was a pain in the as*..
Why is there no "delete" button for a whole package and for tags?

Like possible at DockerHub.

@the-hotmann commented on GitHub (Dec 1, 2024): Also deleting single "layers" was a pain in the as*.. Why is there no "delete" button for a whole package and for tags? Like possible at DockerHub.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10927