Non-digested containers-storage references should resolve to the manifest that exists about image

[mtrmac]

This affects not just @id references, but also all tagged references (where a manifest digest is not provided by the caller).

The original report is about a multi-arch manifest where we have only pulled a non-default architecture and consuming the multi-arch manifest the usual way would look for a manifest which we don’t have.

There’s another problematic case: if we are validating signatures for a specific name, we need to find the manifest that is signed under that name (if multiple manifests, some signed, some not, end up being stored in the same deduplicated image). We don’t currently, by default validate signatures in c/storage during ordinary Podman operation, but CRI-O wants to introduce that around cri-o/cri-o#7046 .

In that case we probably need to maintain native RepoTags records (name:tag → digest, not just name@digest) to be able to find “the right” manifest without having to parse signatures. But that would also make handling the non-default-architecture case even harder, because we would explicitly record that we want to refer to the multi-arch manifest. ?!

I.e. users who pull an image with a non-default architecture option would have to also later consume it with a non-default architecture option. That’s somewhat plausible for a single-image operation, but it completely breaks down for podman images and similar operations which want to work with all images.

So, I guess, instead of “the obvious RepoTags” we would need to record “resolved RepoTags”, where we don’t point at the multi-arch manifest list, but only at the per-arch manifest. Or, possibly, record both, one for reporting to users in inspect, and one for actual image lookups?!