Skip to content

Add artifactType to image index#1066

Merged
vbatts merged 1 commit intoopencontainers:mainfrom
AaronFriel:friel/artifact-index
Jun 15, 2023
Merged

Add artifactType to image index#1066
vbatts merged 1 commit intoopencontainers:mainfrom
AaronFriel:friel/artifact-index

Conversation

@AaronFriel
Copy link
Copy Markdown
Contributor

@AaronFriel AaronFriel commented May 25, 2023

It would be useful for implementations which generate multiple artifacts, each with their own platform or other metadata and perhaps, associated signatures, attestations, to be able to index them all in a single image index.

As an implementer, I'm considering having a top level "package" stored as an image index, which then references all the artifacts in the package as artifacts (image manifests). The artifactType of the image index would be "application/...package", and the artifactType of the image manifests could be:

  • "application/...plugin" with annotations and/or platform fields set to indicate that it is the plugin for, e.g., macOS with Apple Silicon (darwin-arm64)
  • "application/...schema" with annotations indicating this is a separate artifact
  • ... other artifact types as needed

Using an image index in this use case is helpful as we would want to associate SBOMs, signatures to the individual artifacts references, so that a client only needs to download and verify the artifacts it consumes selects from the index.

@tianon
Copy link
Copy Markdown
Member

tianon commented May 25, 2023

(#1020 is also very related 👀)

@sudo-bmitch sudo-bmitch added this to the v1.1.0 milestone May 25, 2023
It would be useful for implementations which generate multiple artifacts, each
with their own platform or other metadata and perhaps, associated signatures,
attestations, to be able to index them all in a single image index.

As an implementer, I'm considering having a top level "package" stored as an
image index, which then references all the artifacts in the package as artifacts
(image manifests). The artifactType of the image index would be
"application/...package", and the artifactType of the image manifests could be:

* "application/...plugin" with annotations and/or platform fields set to
  indicate that it is the plugin for, e.g., macOS with Apple Silicon
  (darwin-arm64)
* "application/...schema" with annotations indicating this is a separate artifact
* ... other artifact types as needed

Using an image index in this use case is helpful as we would want to associate
SBOMs, signatures to the individual artifacts references, so that a client only
needs to download and verify the artifacts it consumes selects from the index.

Signed-off-by: Aaron Friel <mayreply@aaronfriel.com>
@AaronFriel AaronFriel force-pushed the friel/artifact-index branch from 136f1bb to 749ea9a Compare June 1, 2023 17:16
Copy link
Copy Markdown
Member

@sajayantony sajayantony left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This aligns with #1020 and defines these fields that can be used by artifact authors. These are optional fields and having them enables distribution spec to return indexes that may be referrers to other artifacts.

Copy link
Copy Markdown
Member

@tianon tianon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is reasonable (even separately from #1020, now that I've looked at it again with fresh eyes) 🙇

@sajayantony
Copy link
Copy Markdown
Member

Need to update the json schema and the go-specs. I can do that up as follow up PR.

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 this pull request may close these issues.

5 participants