Is your feature request related to a problem?
Hi,
As part of supporting air‑gapped deployment of notation‑signed blobs and images, we have "encountered" a limitation: notation verify only accepts what I would describe as a “regular” folder as input.
What solution do you propose?
Ideally, it would be useful to support use cases such as:
notation verify --oci-layout ./hello-world.tar.gz --scope "local/hello-world"
and/or allow reading the OCI layout from stdin, for example:
zcat hello-world.tar.gz | notation verify --oci-layout --scope "local/hello-world"
The command-line examples above are for illustration purposes only; any approach that enables this use case would be ok.
The target scenario is to extract (oras cp ) blobs/images from a registry and import them into an air‑gapped environment. OCI layouts can become quite large when not compressed, so being able to process compressed archives directly would significantly improve efficiency.
What alternatives have you considered?
- Compress the oci layout for transport (usb stick like solution) and uncompress the whole thing on the other end.
Verify and load
=> Seen as not space efficient enough
- Compress and sign the tarball (outside notation / registry), make the reciever verify the tarball signature and blindly load images
=> Imply another signature only for transportation, not relevant since images/blobs are already signed.
Any additional context?
No response
Is your feature request related to a problem?
Hi,
As part of supporting air‑gapped deployment of notation‑signed blobs and images, we have "encountered" a limitation: notation verify only accepts what I would describe as a “regular” folder as input.
What solution do you propose?
Ideally, it would be useful to support use cases such as:
notation verify --oci-layout ./hello-world.tar.gz --scope "local/hello-world"and/or allow reading the OCI layout from stdin, for example:
zcat hello-world.tar.gz | notation verify --oci-layout --scope "local/hello-world"The command-line examples above are for illustration purposes only; any approach that enables this use case would be ok.
The target scenario is to extract (oras cp ) blobs/images from a registry and import them into an air‑gapped environment. OCI layouts can become quite large when not compressed, so being able to process compressed archives directly would significantly improve efficiency.
What alternatives have you considered?
Verify and load
=> Seen as not space efficient enough
=> Imply another signature only for transportation, not relevant since images/blobs are already signed.
Any additional context?
No response