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

Clarify conditions under which the registry may reject a manifest for having non-existent references #442

Closed
andaaron opened this issue Jul 7, 2023 · 2 comments · Fixed by #445

Comments

@andaaron
Copy link

andaaron commented Jul 7, 2023

This wording really bothers me, as is sounds contradictory and interpretable.

A registry MAY reject a manifest of any type uploaded to the manifest endpoint if it references manifests or blobs that do not exist in the registry.
A registry MUST accept an otherwise valid manifest with a `subject` field that references a manifest that does not exist, allowing clients to push a manifest and referrers to that manifest in either order.

The second line mentions the subject reference can point to a manifest which does not exist. On the other hand the first sentence allows the registry to reject the incoming manifest in such a case.

I understand the reason why some references are more equal than others, but let's make that clear. Maybe rephase:

A registry MAY reject a manifest of any `mediaType` uploaded to the manifest endpoint if its properties or type `descriptor` reference blobs that do not exist in the registry, with the exception of the reference in the property `subject`. 
A registry MUST accept an otherwise valid manifest with a `subject` field that references a manifest that does not exist, allowing clients to push a manifest and referrers to that manifest in either order.
All other properties of type `descriptor`, such as `config`, `layers` or `manifests`, which are not empty, SHOULD point to blobs which are already present on the registry, and the registry MAY reject the upload in case they are missing.

Or is this too much detail?

See https://github.com/opencontainers/distribution-spec/blob/main/spec.md?plain=1#L209

@sudo-bmitch
Copy link
Contributor

I agree that's been awkward phrasing. Have a look at #445 and let me know if that's easier to read.

@andaaron
Copy link
Author

andaaron commented Jul 8, 2023

#445 Looks good from my side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants