[Bug]: Fetching Empty OCI Configs with Artifact Types #2977
Labels
Comments
|
Isn't the client supposed skip the pull of This being the config |
|
@andaaron I think that is a valid point, and I mostly agree. However, IMHO I do not believe it would be a good practice to assume that all clients do this optimization; especially since this is an optional field which, to my knowledge, the OCI Image and Distribution Specifications do not explicitly require clients to utilize. In any case, the Distribution spec does not explicitly define how to pull configs - only manifests and blobs. Referring to the blobs section, "A GET request to an existing blob URL MUST provide the expected blob...". We can see Zot does not provide the content as required per the distribution spec. With < Response Status: "200 OK"
< Response headers:
"Content-Length": "0"
"Content-Type": ""
"Docker-Content-Digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a"
"Date": "Thu, 20 Feb 2025 14:46:51 GMT"Similarly, if we hit the blobs endpoint directly with > GET /v2/REDACTED/blobs/sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a HTTP/2
> Host: REDACTED
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< content-length: 0
< content-type: */*
< docker-content-digest: sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
< date: Thu, 20 Feb 2025 17:32:52 GMT
< x-envoy-upstream-service-time: 65
< server: istio-envoy
|
|
The empty config is not stored as a blob. And I assume the client did not push it as a separate blob either (I can check though) if the client had pushed it, it would have been there to be pulled. Will double check, but in general if the client didn't push the config blob to the /blobs endpoint, we can't expect zot to serve it. |
|
The empty config is not stored as a blob. And I assume the client did not push it as a separate blob either (I can check though) if the client had pushed it, it would have been there to be pulled. Will double check, but in general if the client didn't push the config blob, we can't expect zot to serve it. What client pushed the image/artifact/manifest to zot? |
|
I've been testing with both the |
|
@nathan-joslin you could turn off zot dedupe and gc for your testing. |
|
This is really strange. The issue does not reproduce with the data below: cat oci/index.json | jq
{
"schemaVersion": 2,
"manifests": [
{
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"digest": "sha256:a4d2f252e858117bc09a285ed90101b51dfaf62e091a423487454811f5e7ee4a",
"size": 502,
"annotations": {
"org.opencontainers.image.created": "2025-02-23T16:30:28Z",
"org.opencontainers.image.ref.name": "hello"
},
"artifactType": "application/vnd.example+type"
}
]
} |
|
Working for: Tested again, this time with clean storage: |
|
@nathan-joslin, what are the exact commands you are using to push the artifact to zot? |
|
@andaaron One method I've used is $ oras version
Version: 1.2.2+Homebrew
Go version: go1.23.4After attempting the reproduce with a fresh zot instance deployed to a local kind cluster it seems to work fine. Perhaps this is another issue... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
zot version
v2.1.2
Describe the bug
The OCI Image specification includes a section on Guidelines for an Empty Descriptor and Guidelines for Artifact Usage.
From these guidelines, registries should be able to handle manifests that take the following form; which is the same as instance 2 from the Guidelines for Artifact usage but with the optional data field in the config descriptor. When fetching the config of such an artifact, Zot registry returns no content; instead of the expected empty config
{}.{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "artifactType": "application/vnd.example+type", "config": { "mediaType": "application/vnd.oci.empty.v1+json", "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", "size": 2, "data": "e30=" }, "layers": [ ...] }It's worth noting Zot registry properly handles a similar use case, which does not use a manifest Artifact Type; instead using a custom config mediatype and without the optional data field. This use case is a notation signature:
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.cncf.notary.signature", "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", "size": 2 }, "layers": [ ...] }To reproduce
artifactTypeand an empty descriptor. Similar to:{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "artifactType": "application/vnd.example+type", "config": { "mediaType": "application/vnd.oci.empty.v1+json", "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", "size": 2, "data": "e30=" }, "layers": [ ...] }Fetch the config with
oras, i.e.oras manifest fetch-config {ZOT_OCI_REF}.Error:
Error: GET "https://{ZOT_OCI_REF}/blobs/sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a": mismatch Content-LengthNOTE: Other methods of pulling the OCI config may trigger similar errors, for instance
oras blob fetch -o - {ZOT_OCI_REF}results inError: mismatched digest. All of which are related to returning no content rather than the expected empty config{}.Expected behavior
As mentioned previously, the expected behavior is similar to how Zot registry already handles a similar manifest; which doesn't use a manifest artifactType and instead a custom config mediatype.
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.cncf.notary.signature", "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", "size": 2 }, "layers": [ ...] }Screenshots
No response
Additional context
Adding the
--debugflag to oras commands may be helpful.The text was updated successfully, but these errors were encountered: