In reply to@_slack_opencontainers_UGGPC8W85:matrix.org
Hey artifact folks, For those that have been following the Notary v2 work, we've been approaching this in three areas of focus: 1. Definition of a Notary v2 Signature 2. Registry Persistence, Discovery and Retrieval 3. Key Management The intent is to support signing all content (OCI Artifacts) persisted in a registry, assuring the integrity from the point content enters a registry, as it's promoted within and across different registries, to the point of consumption. To support the Notary v2 goals of not changing the tag or digest of an artifact when signing, we've focused on linking artifacts, including signatures and other artifacts like SBoMs.  This provides a lot of power to store all sorts of content types, including graphs of objects. In the OCI working group, we've been discussing various approaches from changes to the existing OCI Image manifest (adding references to descriptors and clarifying use of the previously reserved descriptor data element) to defining a new oci.artifact.manifest spec that defines a subset of restrictions of the image.manifest, with a super set of capabilities, including manifest references. We've been debating the approach for how to leverage the registry infrastructure since the adoption of OCI Artifacts effort. The debates ranges from whether we should support anything other than container images, to how we support identifying what we realized was already happening. Users have long since been putting other content in a registry, they just made it look like a container image. Due to concerns around changing the schema of the oci.mage.manifest and breaking all the existing clients, the initial OCI Artifacts approach settled on using the image.manifest.config.mediaType to identify what the content represented.  This enabled users that were masking their content as an oci.image to clearly identify the usage. With addition of the ORAS libraries, an ever expanding set of new artifact types have surfaced, including Helm Chart, OPA, WASM. Singularity Image. We knew we needed more and this was just the beginning. We discussed adding a config to the oci.image.index and other various efforts to support additional artifact types, but kept bumping into constraints and realizing we were stretching the limit for what the manifests could support. We talked about refactoring the manifests which led to the new oci.artifact.manifest spec. However Justin Cormack has been noodling on the larger problem we've face with multi-arch manifests (image.index), artifact references, and versioning of the content, such as new gzip or stargz compression formats. Today, Justin provided a more generic, "one manifest to rule them all" approach. Generic Format for Registry Documents As registry operators, I'd suggest reading through this doc. Justin will get it posted somewhere for easier comments on specific lines. Will this be a big change? Yes. Is it worth it? If you're running distribution, you're more than likely supporting multiple artifact types. Whether it be Helm charts as OCI Artifacts, or running npm, nuget, maven and other package managers in your broader line of supported services. In Azure, we've proven we can support all package managers with the infrastructure of registries. We'd like to see this more generically possible, as we believe consuming public content should be promoted into a registry you control for the secure management for your systems. We believe the changes to support reference types, and identifying a versioned document will have far more reaching impact. In the short term, we believe the value of securing the integrity of content in a registry will justify the value for adopting a new artifact manifest. It will mean garbage collection is a bit harder as we'll have cross artifact references to ref-count. The value to also support SBoMs and other types will hopefully justify the investment. • At the minimum, please read Generic Format for Registry Documents • For more context of the scenarios, you can review: OCI Artifact Manifest overview Most of all, let us know what you think. We'll be reviewing this in more detail at the OCI Weekly meeting, next Wednesday. I'll see if we can get this added to our Tuesday CNCF Distribution meeting as well.

In reply to@_slack_opencontainers_U01SK8TEV42:matrix.org
A bunch of actionable items were preempted last Wednesday, I'd like to suggest we make some time to cover these as well before coming back to this doc, out of fairness and respect for everyones time.

In reply to@_slack_opencontainers_U01SK8TEV42:matrix.org
In particular the questions about whether or not the image spec is "locked"