Consider adding a SystemContext override for use-sigstore-attachments

[dmesser]

As a user of skopeo I would like an additional flag for skopeo to automatically pick up cosign-style signatures artifacts when copying a single image or a series of images using skopeo copy and skopeo sync so I can copy the signature artifacts over automatically with the image(s) that are getting copied.

While the larger background is the missing specification of OCI references types which is currently discussed here, cosign adopted a fairly straight forward and portable approach to associate images and their signatures stored as OCI artifacts (sort of) with a naming convention. For a given image the signature is expected in the same repository in a manifest tag named like this:

sha256-<sha256_checksum_of_image>.sig

Upon providing a the flag, skopeo should be able to probe during the copying process if such a tag exist and simply copy it over as well, retaining the name.

This is sort of a pre-cursor to let skopeo verify signed images during manifests getting copied / sync'd around (#1533). The use case for simple signature copy is to allow mirroring of signed images for the benefit of being able to verify those images in the target registry. Sometimes the environment of the target registry is even disconnected by a physical air-gap.

Background: Quay is a heavy user of skopeo and would like to rely on it natively to capture potential signature artifacts during repository mirror configurations.

[mtrmac]

Thanks for your report.

Conceptually this is a c/image feature, where c/image should treat mostly the attachments as part of the primary image (for purposes of format conversion and non-registry transport support), so moving there.

I’m currently tentatively thinking that this would be a per-registry/per-repo option in registries.d whether to look for the signature / attachment images when copying other data (to avoid extra round-trips on every image access, especially Docker Hub users tend to be antsy about those); the default might start opt-in but could change over time.

It’s a bit more complicated in the skopeo sync case, because skopeo sync listing all tags would naively trigger copying the signatures twice — once as a part of the primary image, once as an individual artifact. Short—term that doesn’t hurt other than the extra time/duplication of effort, eventually we might want to filter those duplicates out (while still copying stray attachments?).

[dmesser]

I'd propose to still have a CLI option for skopeo sync|copy as well as a YAML spec for skopeo sync to ease opt-in.

[mtrmac]

An option to do what?

I’d much prefer not to add a special-case code, and an option, to skopeo copy, only for that to be obsoleted/made redundant by a c/image feature a few weeks afterwards.

(Also note that a full repo sync with skopeo sync will copy the tagged signatures just as well without having to understand them at all — apart from containers/image#1574 being necessary, but that’s necessary either way.)

[dmesser]

An option to enable/disable copy of cosign-style signature artifacts. skopeo copy copies a single manifest (list) and as a user I may not want to have to fiddle with an extra config file only in order to express a common preference to copy the signature with it. skopeo sync depending on the tag filter expression may not capture the tagged signatures.

[mtrmac]

Ah, an option as an alternative to the registries.d per-registry configuration? That makes sense.

[mtrmac]

The functionality now exists, as of containers/image#1595 (although there wasn’t a c/image release since).

It is configured via use-sigstore-attachments in registries.d, there isn’t a Go-level override yet.