Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider copying associated cosign artifacts #1946

Open
ralphbean opened this issue May 5, 2023 · 1 comment
Open

Consider copying associated cosign artifacts #1946

ralphbean opened this issue May 5, 2023 · 1 comment
Labels
kind/feature A request for, or a PR adding, new functionality

Comments

@ralphbean
Copy link

It would be nice if skopeo copy supported the naming convention used by cosign triangulate to additionally copy cosign artifacts when copying an image.

# Let's start with this image as a source
SOURCE=quay.io/redhat-user-workloads/ralphjbean-tenant/demo/python-app-trgx
TAG=1d9d889b9cb12c4809c742e65fdee6a059838d3f

# Observe in stdout that there are cosign attestations and a signature present
cosign tree $DESTINATION:$TAG

# Let's copy it to this destination. Your choice!
DESTINATION=quay.io/your/repo

# Copy just the image, see that the attestation data cannot be found
skopeo copy docker://$SOURCE:$TAG docker://$DESTINATION:$TAG
cosign tree $DESTINATION:$TAG

# User can do this themselves, but it would be nice if it were automatic with a flag to the initial skopeo copy, above
DIGEST=$(skopeo inspect docker://$SOURCE:$TAG | jq -r .Digest | sed 's/:/-/')
for SUFFIX in sig att sbom; do
    skopeo copy docker://$SOURCE:$DIGEST.$SUFFIX docker://$DESTINATION:$DIGEST.$SUFFIX
done

# Confirm that the signatures and attestation data are relocatable
cosign tree $DESTINATION:$TAG

Related: https://blog.sigstore.dev/cosign-image-signatures-77bab238a93/

@mtrmac
Copy link
Collaborator

mtrmac commented May 5, 2023

Thanks for your report.

Currently (with an use-sigstore-attachments opt-in) we read data from the .sig tag; not from the .att nor .sbom tags used here.

Adding the other ones seems reasonable short-term (or maybe we should just wait for https://github.com/opencontainers/distribution-spec/blob/main/spec.md#listing-referrers or at least the intermediate referrers compat API?).

We would need to figure out how to opt-in; is that a global property per-repo or per operation?


Either way, this would almost all happen in c/image, so moving there.

@mtrmac mtrmac transferred this issue from containers/skopeo May 5, 2023
@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Jun 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality
Projects
None yet
Development

No branches or pull requests

2 participants