Invalid platform / displayed + misc UI feedback
#475
Comments
Including handling indexes / manifest lists for buildkit manifest lists containing image cache See - project-zot/zui#475 - project-zot#3000 (comment) Fix and unrelated issue with killing zot and collecting logs in case of cluster test failures Signed-off-by: Andrei Aaron <[email protected]>
Will fix this as part of project-zot/zot#3019
Will fix this as part of project-zot/zot#3019
Will need to see how we can handle this.
With regards to the cube icon, that is supposed to be a customizable image by encoding it into a specific annotation.
Not sure what to do about it. I don't think we want to add custom logic based on docker specific annotations in the zot or UI code. |
My point was you don't have the ability to select So rather than Docker specific, it was more about not presenting these invalid platforms in the first place. AFAIK, once Docker moves it's default publishing to OCI compliance this behaviour won't remain (at least from what I understand, attestations artifacts for an image would rely on Referrers API or Referrer Tag schema for discovery, nothing in the image index that Docker is presently doing). OCI compliant typesHere's how to reproduce with OCI compliant types. NOTE: This differs from earlier screenshot that rendered FROM alpine
RUN echo 'hello' > /tmp/hello.txt# Docker Engine 28.0.1, buildx v0.21.1, BuildKit 0.20.0
# Run zot
docker run --rm -d --name zot -p 127.0.0.1:5000:5000 ghcr.io/project-zot/zot:v2.1.2
# Build image and push to zot
# Differs from defaults with:
# - x86_64 + aarch64 multi-arch image
# - Full provenance (instead of minimal, forces using an index even if only a single platform)
# - OCI media types for manifest/index and artifacts (instead of Docker equivalent types)
docker buildx build --builder custom-builder \
--output 'type=image,push=true,oci-mediatypes=true,oci-artifact=true' \
--platform 'linux/amd64,linux/arm64' \
--provenance true \
--tag localhost:5000/hello/world:example \
.Inspecting their content is not that useful either: The actual OCI artifacts they reference aren't visible or possible to navigate to via the UI? I've documented that here, as the "Referred By" view doesn't appear to be functional for discovery. |
If you get involved on the It was non-obvious how to opt-out (for ephemeral
That's fine. I have no issue with the icon itself really, but the initial impression was the colours had some meaning associated to them (like is documented for vulnerabilities) and then the observation that the colour was non-deterministic, just randomly selected. I think it'd be better to just keep the colour fixed. GHCR for example just has a monochrome container icon: |
Sorry, I don't have the time now to go through your investigation in detail today, but this stood out to me. Given one of your examples using OCI media types: Handling these annotations count as referrers is not part of the OCI spec: So we don't handle the manifest An actual referrer per OCI spec is a manifest such as (also from one of your examples): This manifest is a referrer of Later edit: But we can't have zot/zui ignore entries in the index.json because they have this specific annotation |
I am aware it is not OCI spec. I assume Docker uses that with it's own tooling, I haven't tracked the timeline of the OCI Referrer spec but it's possible that Docker had been doing their own approach before there was an OCI standard and this is effectively legacy with the For reference I split out the concern with Referrers API / discovery to this issue. The associated content in this issue is about how that is rendered in
I've published with OCI compliant types,
? My request is to ignore is unrelated to the Docker annotations, but the fact that AFAIK there is no user-facing value of: "platform": {
"architecture": "unknown",
"os": "unknown"
}Gitea registry hides this. GHCR does not. I have noticed zui doesn't show referrer tag schema tagged indexes like GHCR does, so zui is already hiding some information as-is. |
Those are only a workaround for older registries not having a referrers API. Clients should not use this tag if the API is available. Maybe the client checks the API first? Not sure if we intentionally hide it.
Understood, but that's the data coming from the image itself. If the image builder decided to use "unknown" I think we should show it as is. Simply showing |
Including handling indexes / manifest lists for buildkit manifest lists containing image cache See - project-zot/zui#475 - project-zot#3000 (comment) Fix and unrelated issue with killing zot and collecting logs in case of cluster test failures Signed-off-by: Andrei Aaron <[email protected]>
To clarify,
My stance for these sorts of things are when there are valid use-cases to support rather than supporting unknown what-ifs 😅 As such I think Gitea is doing it right to not treat it as a valid image platform to present to the user. I think the information can still be presented via raw JSON being displayed on demand instead? Or like this issue notes for troubleshooting/observability reasons, but not necessarily as part of the primary UX until there's a valid scenario where that information is of value? Presently you'll find reports of users complaining about such on other registries that have rendered it. Especially when users attempt to pull it since the registry treats it like any other platform. You would still be able to attempt a pull, but until there is a valid use-case for
For context,
|
Including handling indexes / manifest lists for buildkit manifest lists containing image cache See - project-zot/zui#475 - #3000 (comment) Fix and unrelated issue with killing zot and collecting logs in case of cluster test failures Signed-off-by: Andrei Aaron <[email protected]>
|
I have tried with docker buildx build --builder custom-builder \
--output 'type=image,push=true,oci-mediatypes=true,oci-artifact=true' \
--platform 'linux/amd64,linux/arm64' \
--provenance true \
--tag localhost:5000/hello/world:example \
.This will still render the Problem: If I instead set ComparisonNOTE: Below I run two oras manifest fetch localhost:5000/hello/world:example \
| jq -r '[ .manifests[]
| select(.annotations | has("vnd.docker.reference.digest"))
| .digest
] | first' \
| oras manifest fetch "localhost:5000/hello/world@$(cat -)"
|
I checked and we don't add the referrers tag to our DB on push, That's why we don't return it. |
Shouldn't the query to
Is this in relation to an actual referrers tag being created at the My understanding of Even when a referrer tag is specifically created, the referrer API support in Or is this meant to be a |
|
The UI doesn't call the referrers REST API, it calls a graphql endpoint which queries a DB on zot side. It's a different implementation. That doesn't have anything to do with the UI not showing the content for |
|
With regards to #475 (comment). In case of Given the error messages in one of your other issues, which you also mentioned above: Later edit, this looks like opencontainers/image-spec#1192 @rchincha We should update to the latest image spec. |
|
TL;DR: I can confirm that the artifact
Right.. this is probably because I'm thinking of the platform being inferred from the image index JSON that a registry would normally derive this information from AFAIK? EDIT: As confirmed below, the info is being sourced from each individual manifest
You are correct, the artifact ( oras manifest fetch-config --pretty \
localhost:5000/hello/world@sha256:85c58175832585eeae3a36e3211e7f6f62a9e6c4ef8f75c199cf3aa5214387d1{
"architecture": "unknown",
"os": "unknown",
"config": {},
"rootfs": {
"type": "layers",
"diff_ids": [
"sha256:6510340fa92b62fd4fb596421dca5e8686c3274e2b572a50e971bfa66e990835"
]
}
}EDIT: Here is the official Docker docs on the attestation
Meanwhile, the OCI artifact with empty config: $ oras manifest fetch-config --pretty \
localhost:5000/hello/world@sha256:05774b462cb207aa3dded9d0d9c9943054c6aa26a29eec6ea13a9969974af1be
{}If it is helpful, here is the associated JSON attachment (provenance attestation) for that artifact: Inspecting the OCI artifact layer contentContent is effectively the same and platform is encoded. oras blob fetch --output - \
localhost:5000/hello/world@sha256:6510340fa92b62fd4fb596421dca5e8686c3274e2b572a50e971bfa66e990835 \
| jq .{
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "https://slsa.dev/provenance/v0.2",
"subject": [
{
"name": "pkg:docker/localhost%3A5000/hello/world@test-f?platform=linux%2Famd64",
"digest": {
"sha256": "a42bc525fcf382ea7160b037fe72444dc5a415bf8c874e9432814d22ddb61dda"
}
}
],
"predicate": {
"builder": {
"id": ""
},
"buildType": "https://mobyproject.org/buildkit@v1",
"materials": [
{
"uri": "pkg:docker/alpine@latest?platform=linux%2Famd64",
"digest": {
"sha256": "a8560b36e8b8210634f77d9f7f9efd7ffa463e380b75e2e74aff4511df3ef88c"
}
}
],
"invocation": {
"configSource": {
"entryPoint": "Dockerfile"
},
"parameters": {
"frontend": "dockerfile.v0",
"locals": [
{
"name": "context"
},
{
"name": "dockerfile"
}
]
},
"environment": {
"platform": "linux/amd64"
}
},
"metadata": {
"buildInvocationID": "s2wchebzazfrqwbze11we5aay",
"buildStartedOn": "2025-03-11T20:19:23.204656792Z",
"buildFinishedOn": "2025-03-11T20:19:24.672025931Z",
"completeness": {
"parameters": true,
"environment": true,
"materials": false
},
"reproducible": false,
"https://mobyproject.org/buildkit@v1#metadata": {}
}
}
}ReferenceExpand for additional reference comparisonsEarlier shared build commandFROM alpine
RUN echo 'hello' > /tmp/hello.txtdocker buildx build --builder custom-builder \
--output 'type=image,push=true,oci-mediatypes=true,oci-artifact=true' \
--platform 'linux/amd64,linux/arm64' \
--provenance true \
--tag localhost:5000/hello/world:example \
.The next two sections provide reproduction + output of
|
For reference Docker attestation docs detail their Docker specific annotations and image index usage with attestations using It rather clearly states the intention is to prevent pulling. It's only purpose was to assist traversal/discover prior to supporting |
provenance: false is still necessary
docker-mailserver/docker-mailserver#3582
As side effect the warnings mentioned in project-zot/zui#475 (comment) should no longer show up. Signed-off-by: Andrei Aaron <[email protected]>
As side effect the warnings mentioned in project-zot/zui#475 (comment) should no longer show up. Signed-off-by: Andrei Aaron <[email protected]>
As side effect the warnings mentioned in project-zot/zui#475 (comment) should no longer show up. Signed-off-by: Andrei Aaron <[email protected]>
As side effect the warnings mentioned in project-zot/zui#475 (comment) should no longer show up. Signed-off-by: Andrei Aaron <[email protected]>
chore: update image-spec and dist-spec to v1.1.1 As side effect the warnings mentioned in project-zot/zui#475 (comment) should no longer show up. Signed-off-by: Andrei Aaron <[email protected]>
|
Some fixes for these issues #477 and project-zot/zot#3023. |
Describe the bug
Since
zot2.1.2 there is support for Docker media types instead of only OCI. However the UI fails to recognize / display the image arch, instead rendering as/.To Reproduce
Reproduction instructions to build and push along with associated manifest config can be found here.
Expected behavior
Consistency with platform info (it is there just like OCI media types provide).
Screenshots
OCI compliant platform renders correctly, but in this case there is an
unknown/unknownplatform which is equally invalid (misuse for provenance attestation artifacts by Docker AFAIK?), other image registries like Gitea have this platform filtered out:Additional context
Related UX concerns (or allow to be configurable):
extensions.search.cveis missing from config), don't display the "Failed to scan" badge as it is meaningless?unknown/unknownplatform technically shouldn't be displayed as a platform selection. It is presented in the list of arch chips beneath an image description and can be filtered at/explore?filter=unknown(but not available as a selectable filter understandably).The text was updated successfully, but these errors were encountered: