Project

Profile

Help

Issue #2992

GET by manifest digest should infer media type

Added by twaugh about 3 years ago. Updated over 1 year ago.

Status:
CLOSED - WONTFIX
Priority:
Normal
Assignee:
-
Start date:
Due date:
Estimated time:
Severity:
1. Low
Version - Crane:
master
Platform Release:
Target Release - Crane:
OS:
Triaged:
No
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

When issuing a GET request for a manifest (schema 1, schema 2 image manifest, or schema 2 manifest list) by its digest, the Docker Distribution registry returns the requested object regardless of any Accept: header in the request.

Is it possible for Crane to do this? I guess it isn't because it would need to be told the full inventory of manifest digests... just noting the discrepancy and asking the question. I'm not away of any specific problem this causes right now.

Right now if there is (for example) a manifest list at sha256:0123456..., a GET request for /v2/{name}/manifests/sha256:012346... but without any Accept: header redirects the client to /pulp/docker/.../manifests/1/sha256:012346..., not to the .../list/... location.

Perhaps there is a way of achieving this using symbolic links in /pulp/docker?

History

#1 Updated by ttereshc about 3 years ago

@ipanova will take look and we will triage it next time.

#2 Updated by ipanova@redhat.com about 3 years ago

right now Crane works the way registry works if a docker client talks to it( through docker engine).

Registry bases its logic on the headers sent from the docker client.

so if looking at the case you've mentioned:

Right now if there is (for example) a manifest list at sha256:0123456..., a GET request for /v2/{name}/manifests/sha256:012346... but without any Accept: header redirects the client to /pulp/docker/.../manifests/1/sha256:012346..., not to the .../list/... location.

Registry looks at the headers. there are none there, that implies that it is an older docker client and registry will try to convert it to schema1 but the problem is that the manifest is pulled by digest and not tag this would lead to ( taking form docker docs)

When the manifest is pulled by _digest_ with Docker Engine 1.9 and older, the same rewriting process will not happen in the registry. If this were to happen the digest would no longer match the hash of the manifest and would violate the constraints of CAS.

For this reason if a manifest is pulled by digest from a registry 2.3 with Docker Engine 1.9 and older, and the manifest was pushed with Docker Engine 1.10, a security check will cause the Engine to receive a manifest it cannot use and the pull will fail.

https://docs.docker.com/registry/compatibility/

In Crane case it would redirect to schema1 and it would lead to 404
if we would 100% mimic the registry behavior, the final result will any lead to a manifest pull which would eventually fail.

I don't think we covered the cases of direct API calls, we would always rely of the fact that there is a 'docker pull', which is smarter and sets the headers accordingly.

#3 Updated by twaugh about 3 years ago

OK, that's totally fair.

#4 Updated by ipanova@redhat.com about 3 years ago

based on the discussion with Tim, we can close it.

#5 Updated by ipanova@redhat.com about 3 years ago

  • Status changed from NEW to CLOSED - WONTFIX

#6 Updated by bmbouter over 1 year ago

  • Tags Pulp 2 added

Please register to edit this issue

Also available in: Atom PDF