Skip to content
This repository was archived by the owner on Sep 23, 2022. It is now read-only.

Latest commit

 

History

History
82 lines (78 loc) · 5.08 KB

2022-04-05.md

File metadata and controls

82 lines (78 loc) · 5.08 KB

Date

April 5, 2022

Attendees

  • Lachlan Evenson
  • Brandon Mitchell
  • Josh Dolitsky
  • Jason Hall
  • Ramkumar Chinchani
  • Sajay Antony
  • Steve Lasker
  • Marina Moore

Notetaker

  • Jason 🥇
  • Brandon Mitchell 🥈

Agenda

  • Review Proposal A (Sajay)
  • Suggestion for Proposal E (Brandon)

Notes

  • Updates for Proposal A
    • not evolving the Image spec, starting fresh with a new Artifact manifest
    • blobs are not required to be ordered/layered. It's up to each artifactType to specify
    • subject points to another entry (could be "reference")
    • Reference tends to reflect the downward reference - manifest --> blobs. subject is an upward reference. subject is also a generalized term for a pointer in signatures and claims
    • one subject or N subjects?
      • e.g., one signatue signing multiple images
      • start with one
      • subjects pointing to blobs may allow for looping
      • subject points to a single manifest assuring lifecycle managment is possible
    • blobs was going to be ``"descriptors"` (PR#75, but was reverted) -- disallowed to prevent loops
    • artifactType in the descriptor --> moving to an annotation?
      • may make it easier to index for filtering at query-time
    • _oci/artifacts/referrers matches OCI extensions spec
    • Can we move the artifactType to annotations? (Brandon)
    • Nisha: can blobs be interpreted as ordinal?
      • order can't change, or else digest would change
      • could be interpreted as ordered if you want to
    • Nisha: can artifact manifests point to other artifact manifests?
      • Yes. subject can point to any manifest type (index, docker, oci, artifact)
      • Loops are prevented because subject can only point to manifests, not blobs
      • blobs descriptors are only blobs (never manifests)
    • Nisha: this looks like a v3 change, major version bump
      • /v2/ is part of the OCI extensions spec
      • /v2/ already works, supports auth, etc.
      • /v3/ makes registry hosting more difficult
    • Nisha: why do descriptors also include artifactType?
      • to avoid round tripping when querying? (yes)
      • lifting all annotations has concerns, could result in larger size, may make sense to use data field to inject full manifest in reply, bloating the response, and possibly sending exploitable data in a reference
    • Nisha: having params in the API might not be a good idea?
      • e.g., .../sha256:.../referrers
      • OCI extensions spec recommends query params
    • Jason: "subject MUST exist" in some scenarios
      • We should document the use case. (Sajay)
      • open to relaxing that requirement to support offline signing
      • artifact without a subject existing could be removed by GC, a tag could help with this
      • race condition of pushing image and then pushing signature could be an issue for some users that require only signed images
    • Steve: you can push a manifest as a digest, push the signature, than push a tag update assuring the new tag reference is signed
    • Josh: can container images refer to things?
      • or only "artifacts" like this (Sajay: no)
      • be able to tell what images a Helm chart refers to
      • Sajay: solving a specific problem; the goal is not to change the image spec
      • a Helm chart can refer to N images, you could query for images' /referrers to find the Helm chart.
      • an artifact can't point across repos, the images would have to be in the same repo, which is not relevant to helm charts
    • Josh: artifactType should be registered with IANA, should that be a fully qualified media type?
      • Yes, registration prevents multiple implementations fighting over a string
      • Other proposals allow this to be more free form string
    • Brandon: created annotation?
      • is this because we don't have config field anymore?
      • Recommend looking for other needed annotations from the config object and make one PR for all of them.
    • Nisha: could we put subsequent scans in additional (ordered) blobs?
      • Steve: each scan is a new artifact, assuring each can be promoted individually, or a filtered subset (eg: first and last scan), avoiding any contention for updated manifests
  • Proposal E suggestion
    • combination of AB+D
    • new media type, add referrers field, add /referrers API to query, and support digest tags
    • useful to users today, with addl' benefits later when registries support the new media type + APIs
    • Users start with an existing OCI artifact today (image with appropriate config media type), include a reference field
    • Query using digest tags on existing registries and later upgrade to the API against that field
    • Once all registries are upgraded, they can switch over to the new media type to drop the config blob
    • Brandon will write it up and review at a future meeting