Merge pull request #275 from sargun/dedupe-uploads

Allow for automatic content discovery for cross-mounting blobs

FAQ.md

@@ -68,3 +68,16 @@ choose to expire it after, for example, a minute or an hour, in the case that yo
 **Q: What happens if the `<tagname>` (last) parameter does not exist?**
 
 There is no suggested behavior in the specification for what to do if the tag does not exist. Registries might consider ignoring te parameter, or assuming a non-existing tag is at the start or the end of the sorted list. In the first case, at the start of the list would imply returning the entire set of tags. In the second cast, at the end of the list would imply returningan empty list, as it references the last tag onward (an empty set).
+
+**Q: How are clients expected to adopt (and probe for) automatic mount origin discovery?**
+
+The process of mounting a blob is supposed to fail in such a way that if a blob cannot be cross-mounted, the registry the registry initiates an upload. 
+Clients should try to use the automatic content mount origin discovery mechanism when they do not know of an origin in the registry with the requisite blob. 
+Nonconformant registries may return a non-201 or non-202 error code. 
+If the client is trying to be defensive to nonconformant registries, and receives a non-201 or non-202 error code, it should fall back to [pushing the blob](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#pushing-blobs).
+
+**Q: How come `from` is required on cross-repo mount for some registries?**
+
+Mounting without having to specify `from`, also known as automatic mount origin discovery, requires the registry to determine whether or not a blob exists in any repository. 
+If the existence check for the blob is done first, an immediate failure will indicate the lack of presence of a blob. 
+On the other hand, if the registry needs to perform further work to determine if the blob can be accessed by the mounter, it could create an information disclosure risk, in leaking that presence of a blob with that digest in the registry.

spec.md

@@ -357,7 +357,7 @@ Here, `<blob-location>` 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/<name>/blobs/uploads/?mount=<digest>&from=<other_name>`  <sup>[end-11](#endpoints)</sup>.
@@ -376,6 +376,8 @@ 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.
+
 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.