List, inspect and explore OCI container images, their layers and contents • Hacker News Board

Re: List, inspect and explore OCI container images, their layers and contents

#11

Post by bschaatsbergen » Sat, Jan 03, 2026, 8:15 PM UTC

jzelinskie wrote: post #3

I think the most common tools for similar workflows is Google's crane[0] and Red Hat's Skopeo[1]. It might be slightly more low-level than most developers want, though. [0]: https://github.com/google/go-containerregistry/blob/v0.20.7/... [1]: https://github.com/containers/skopeo

Skopeo and crane are both fantastic tools, but they address different problems at a different level. Skopeo and crane operate at the image registry level, handling pulling, pushing, synchronizing, etc. cek is focused on what's in the container itself, providing a programmatic way to explore a container’s (overlay) filesystem and layers with commands like ls, tree, and cat.

Re: List, inspect and explore OCI container images, their layers and contents

#12

Post by bschaatsbergen » Sat, Jan 03, 2026, 8:18 PM UTC

compsciphd wrote: post #9

All these tools demonstrate a major flaw in OCI images. There is no good way to determine what image your current image was built on top of. You can try to infer it from having a world wide list of chainIds and associate known images with their final chainId, but this isn't perfect and then just assume your image's changes are from last_known_chaid_id+1->end 1) many image tags can share a chainId (not terrible proble…

That's, indeed, a spec limitation, not something cek can solve. If you're interested in provenance tracking, you might want to look at Sigstore's cosign attestations or GUAC (Graph for Understanding Artifact Composition).

Re: List, inspect and explore OCI container images, their layers and contents

#13

Post by compsciphd » Sat, Jan 03, 2026, 9:01 PM UTC

bschaatsbergen wrote: post #12

compsciphd wrote: post #9

All these tools demonstrate a major flaw in OCI images. There is no good way to determine what image your current image was built on top of. You can try to infer it from having a world wide list of chainIds and associate known images with their final chainId, but this isn't perfect and then just assume your image's changes are from last_known_chaid_id+1->end 1) many image tags can share a chainId (not terrible proble…

That's, indeed, a spec limitation, not something cek can solve. If you're interested in provenance tracking, you might want to look at Sigstore's cosign attestations or GUAC (Graph for Understanding Artifact Composition).

right. this is me complaining about the spec, not the tools. I've worked on tooling in this space. I simply don't understand why there seems to be no desire to make a simple addition to the spec.