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

Implement OCI artifacts and revert #1672 #1673

Closed
mtrmac opened this issue Jun 11, 2022 · 2 comments
Closed

Implement OCI artifacts and revert #1672 #1673

mtrmac opened this issue Jun 11, 2022 · 2 comments

Comments

@mtrmac
Copy link
Collaborator

mtrmac commented Jun 11, 2022

#1672 changes a repo we use for testing skopeo sync, because that repo has added a Cosign signature, and the code now fails (the immediate cause is that it’s trying to compress the image and we don’t have a mapping for the signature blob’s MIME type).

(Note that the signature is not quite an OCI artifact: it uses an ordinary image‘s config MIME type, just an invalid layer MIME type. Still, OCI artifact support is basically a superset of handling this signature.)

We should teach skopeo sync to handle this image, and then revert #1672.

Independent parts necessary for this:

  • Implement OCI artifact support in c/image. Support OCI artifacts image#1574 , currently mostly works but with FIXMEs about the API and feature set. This should be split into several smaller PRs.
  • The registry we test copying to, on localhost, is a very old version that doesn’t support OCI images at all. https://github.com/containers/automation_images/blob/main/skopeo_cidev/Containerfile#L15 probably needs updating, and then that needs to propagate to Skopeo (and hopefully doesn’t break anything).
  • (Eventually we should to think more about skopeo sync’s behavior in repos with Cosign signatures. It can copy signatures along with the individual signed images, or it can ignore the signature relationships and copy each OCI tag completely independently. It would be weird and inefficient(although not quite broken) if it ended up doing both.)
mtrmac added a commit to mtrmac/automation_images that referenced this issue Jun 13, 2022
... primarily so that it accepts OCI-formatted images.

Proof of concept, as well as other updates necessary
to work with that registry version, are in
containers/image#1574 .

See See containers/skopeo#1673
for more context.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac added a commit to mtrmac/automation_images that referenced this issue Jun 13, 2022
... primarily so that it accepts OCI-formatted images.

Proof of concept, as well as other updates necessary
to work with that registry version, are in
containers/image#1574 .

See containers/skopeo#1673
for more context.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac added a commit to mtrmac/automation_images that referenced this issue Jun 14, 2022
... primarily so that it accepts OCI-formatted images.

Proof of concept, as well as other updates necessary
to work with that registry version, are in
containers/image#1574 .

See containers/skopeo#1673
for more context.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@mtrmac
Copy link
Collaborator Author

mtrmac commented Jul 12, 2022

This was done by #1680.

  • (Eventually we should to think more about skopeo sync’s behavior in repos with Cosign signatures. It can copy signatures along with the individual signed images, or it can ignore the signature relationships and copy each OCI tag completely independently. It would be weird and inefficient(although not quite broken) if it ended up doing both.)

We will end up in the weird situation after #1701, for users that opt into use-sigstore-attachments.

@mtrmac mtrmac closed this as completed Jul 12, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant