Consider how artifacts stored in other locations can be first classed

[sajayantony]

Today the image-spec has hard requirements on things like config blobs which are not needed by clients that might require a blob or 2 to get the bits required. The Artifact manifest serves 2 purpose here

1. Make properties that burden authors optional - e.g. config.
2. Provide a way to link other blobs so that clients can lookup data for verification or supporting functions.

This discussion is about how the registry can be used to store a list of content/artifacts can be discovered and may have the content stored else where. For e.g. the blob might be signed and will have a set of hashes that need to be validated. Consider Github as the main distribution channel for bits but the client can query a registry for manifest to discover the target source.

     ┌────────────┐        ┌────────────────────────────┐
     │            │        │                            │
     │   Client   ├───────►│ registry.io/myartifact:v1  │
     │            │        │                            │
     └────────────┘        └───────┬────────────────────┘
                                   │
                                   │    ┌─────────────────────┐
                                   └─┬─►│     Get Manifest    │
                                     │  └─────────────────────┘
                                     │
                                     │          ┌─────────────────────┐
                                     └─────────►│ Get Blobs from URL  │
                                                └─────────────────────┘

The current behavior is that the clients are expected to first look at /blobs and upon 404 follow the URLs. It would good if the clients had a way to be told to just follow the blob (avoid the unncessary lookup).

Things to consider

• Should clients know how to authenticate to the target URL?
• Should the behavior be option and through annotation or provide a well defined property that enable clients to consider it like a permanent redirect

/cc Credit @awakecoding -

How many tools do nothing more than point to a CDN URL, compare a hash, and then download + decompress in a given directory, if compression there is? Just look at homebrew or chocolatey, it's just URLs to installers/archives, hashes, and a tiny bit of executable code

— Marc-André Moreau (@awakecoding) September 11, 2021

The proposal here is about giving artifact authors and clients guidance on using these annotations to provide client behavior without needed to modifying existing descriptors.

{
    "blobs": [
        {
            "mediaType": "application/text",
            "digest": "sha:....",
            "urls": [
                "https://github.com/oras-project/oras/releases/download/v0.12.0/oras_0.12.0_checksums.txt"
            ],
            "annotations": {
                "org.opencontainers.content.property": "checksum",
                "org.opencontainers.content.location.options": "redirect"
            }
        },
        {
            "mediaType": "application/text",
            "digest": "sha:....",
            "urls": [
                "https://github.com/oras-project/oras/releases/download/v0.12.0/oras_0.12.0_darwin_amd64.tar.gz"
            ],
            "annotations": {
                "org.opencontainers.content.property": "package",
                "org.opencontainers.content.location.options": "redirect"
            }
        }
    ]
}