Consider ignoring OCI 1.1 manifests with dangling subject references
Context
This is part of User Experience for Signed Container Registry I... (&7856). Related to gitlab#404669 (comment 1343829218).
Problem
If we decide to allow dangling subject
references, we must:
- Allow a manifest to be pushed with a
subject
field (referrer manifest) that contains the digest of a manifest (referenced manifest) that does not exist (not yet uploaded or already deleted); - Update online GC to not wipe dangling referrers, i.e., untagged and not referenced by an index.
Doing the above opens a precedent. Right now we enforce strict integrity by hard-linking references, and any untagged/unreferenced manifest is GC'ed (cascading). For the same reason, it's not possible to push a manifest that references another non-existing manifest.
This is key for the implementation of the referrers API (#968), as the client may decide to not tag the referrer manifest (cosign
does not). In those cases, referrer manifests would be GC'ed soon after being pushed.
The fallback tag exists as an alternative to the referrers API, and in that case, it's the client's responsibility to keep a tagged index up to date with the referrers list. Therefore, referrers are not GC'ed, and no changes are required. However, if clients proceed as described here:
When deleting a manifest that has an associated referrers tag schema, clients MAY also delete the referrers tag when it returns a valid image index.
... this would also lead to referrer manifests being deleted (unless they were tagged for some other reason). However, this is already our policy (and GitLab users rely on it to free up storage space): images untagged and not referenced by an index are GC'ed, so this wouldn't be an unexpected consequence for users. Considering that, this is not a blocker for the fallback tag approach IMO.
Similar concerns were brought up by other registry providers in https://github.com/opencontainers/distribution-spec/issues/378. This requires additional consideration.
Considerations
-
Should we accept referrer manifests if the referenced manifest does not exist? Is this a
MUST
according to the spec? -
Should we allow deleting referenced manifests without deleting the corresponding referrer manifests (cascade)? Is this a
MUST
according to the spec? -
Should we not GC untagged referrer manifests? Besides integrity, this has other implications - untagged manifests are invisible to users (GitLab UI/API), and excluded from storage usage calculations (as they are queued for deletion).