From 58c3c06983eeecb5afe023bf13292456e78efd1a Mon Sep 17 00:00:00 2001 From: Sargun Dhillon Date: Fri, 7 May 2021 12:59:43 -0700 Subject: [PATCH] Allow for automatic content discovery for cross-mounting blobs When uploading to multiple registries, the user may or may not what other repositories exist in these registries. Therefore, a client may perform an unnecessary upload when the registry already has a given blob. This an optimization that allows the registry to perform the authz check and check if it can find the blob with a given the passed digest in its blobstore. If that blob is accessible (from an authz perspective) to the user, it can then perform the mount automatically on its behalf. Because there is a potential a timing attack that could be used to disclose knowledge of whether or not the registry has a given blob (for example, a vulnerable version of a Linux image), this an optional feature for registries to implement. Signed-off-by: Sargun Dhillon --- spec.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/spec.md b/spec.md index 18046593..97cb43c6 100644 --- a/spec.md +++ b/spec.md @@ -353,7 +353,7 @@ Here, `` is a pullable blob URL. ##### Mounting a blob from another repository -If a necessary blob exists already in another repository, it can be mounted into a different repository via a `POST` +If a necessary blob exists already in another repository within the same registry, it can be mounted into a different repository via a `POST` request in the following format: `/v2//blobs/uploads/?mount=&from=` [end-11](#endpoints). @@ -372,6 +372,10 @@ The Location header will contain the registry URL to access the accepted layer f header returns the canonical digest of the uploaded blob which MAY differ from the provided digest. Most clients MAY ignore the value but if it is used, the client SHOULD verify the value against the uploaded blob data. +The registry MAY treat the `from` parameter as optional, and it MAY cross-mount the blob if it can be found. + +It MAY cross-mount the blob referred to by the `mount` parameter even if the `from` parameter is omitted. + Alternatively, if a registry does not support cross-repository mounting or is unable to mount the requested blob, it SHOULD return a `202`. This indicates that the upload session has begun and that the client MAY proceed with the upload.