Migrate off of crane for pulling and pushing OCI images

[AustinAbro321]

Describe what should be investigated or refactored

Crane has been an instrumental library to Zarf. It is responsible one of the most core features of our product, pulling and pushing images. However, we've had several issues while using crane. In particular, not accepting context, concurrent pulls and caching of non container OCI images tend to cause trouble. See:

• crane: incorrectly uses compressed layer of a cosign .sig file to write OCI image from cache google/go-containerregistry#1955
• ggcr: Image write concurrency errors google/go-containerregistry#1941
• Unable to use OCI artefacts that are not all image layers #3113
• Context needs to be better passed through to several parts of Zarf so that interrupts can be implemented properly #2594

Alternatives

We should consider alternatives to fix these issues, and open ourselves up to further improvements.

• ORAS (OCI registry as storage) is a project that has become popular in the past few years or so. It is a go library for interacting with OCI registries. We use ORAS already to publish and pull Zarf packages.
• https://github.com/containers/image - this is the library that skopeo uses for image pulls. I have not looked deeply into the code, but it is worth looking at how another successful tool with a similar mission does pulls and pushes

Additional context

Moving off Crane will present challenges. Crane also supports the oci-dir format, which syft uses to scan images local, this is how SBOMs are created during zarf package create. The Crane CLI is embedded directly into Zarf, removing it entirely will no doubt cause a breaking change in the workflow of some users. The Crane CLI has functionality to pull images from the local Docker daemon which would need replacement as well

[AustinAbro321]

Both ORAS and https://github.com/containers/image seem to be reasonable alternatives to Crane. Both accept context, and seem to have more active contributions and updates. Both seem to be faster than crane, more official benchmarks to come. ORAS and "image" supports the same OCI format that Crane and Syft use. "image" supports pulling from the docker daemon while ORAS does not.

ORAS does allow embedding itself into other CLIs with Cobra easily. I am not sure what our appetite for breaking changes are, but it seems to me that it might make sense to deprecate zarf tools Crane and replace it with zarf tools oras. Crane and ORAS share much of the same functionality.

ORAS protect the index.json while pulling concurrently, though it is not clear to my if the current Zarf behavior of pulling many images concurrently is worthwhile to keep. There are situations where having too many network requests for a lot of Gigs may slow things down.

The ORAS CLI has a cache that works with oras-go, but it is not exported. Created an issue track it getting into oras-go - oras-project/oras-go#881

[Silvanoc]

I would recommend you to look at regctl.

[AustinAbro321]

@Silvanoc Thanks for the rec! Taking a look, the big thing this is missing compared to oras-go is a persistent blob cache. That feature is important to our users who often create the same package with the same images multiple times during development.

I do like the CLI UX of this product though. If we decide to replace the zarf tools crane command with a different registry CLI, I think regctl is worth considering.