feat(image): add WASM OCI image support#596
feat(image): add WASM OCI image support#596rodneyosodo wants to merge 1 commit intocontainers:mainfrom
Conversation
Add comprehensive support for WebAssembly OCI images, including WASM content layers, configuration blobs, compression, and encryption. Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>
|
✅ A new PR has been created in buildah to vendor these changes: containers/buildah#6644 |
|
Packit jobs failed. @containers/packit-build please check. |
This updates skopeo dependency of `go.podman.io/image/v5` based on the new changes as of containers/container-libs#596 Signed-off-by: Rodney Osodo <socials@rodneyosodo.com>
mtrmac
left a comment
mtrmac
left a comment
There was a problem hiding this comment.
Thanks, but I can’t see how this could possibly work.
AFAICS the WASM OCI specification doesn’t support compressing layers, so by default I don’t know why we should do so. Is that, at least, a current design discussion in that project?
I feel somewhat similarly about the encryption part, although in there it might be more plausible to just do things without specification… except that the image’s config is not encrypted in the current c/image implementation. Is that really an encryption mechanism to commit to, in this entirely new format?!
As a starting hypothesis, continuing to treat these objects as non-image artifacts should mostly work — sure, without some of the extra features.
| // old image manifests work (docker v2s1 especially). | ||
| func (m *manifestOCI1) OCIConfig(ctx context.Context) (*imgspecv1.Image, error) { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig && m.m.Config.MediaType != internalManifest.WasmConfigMediaType { |
There was a problem hiding this comment.
AFAICS the two objects are not interchangeable and it makes no sense to parse the WASM one as an OCI one.
| // This does not change the state of the original manifestOCI1 object. | ||
| func (m *manifestOCI1) convertToManifestSchema2(_ context.Context, options *types.ManifestUpdateOptions) (*manifestSchema2, error) { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig && m.m.Config.MediaType != internalManifest.WasmConfigMediaType { |
| // This does not change the state of the original manifestOCI1 object. | ||
| func (m *manifestOCI1) convertToManifestSchema1(ctx context.Context, options *types.ManifestUpdateOptions) (genericManifest, error) { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig { | ||
| if m.m.Config.MediaType != imgspecv1.MediaTypeImageConfig && m.m.Config.MediaType != internalManifest.WasmConfigMediaType { |
| func (m *OCI1) Inspect(configGetter func(types.BlobInfo) ([]byte, error)) (*types.ImageInspectInfo, error) { | ||
| if m.Config.MediaType != imgspecv1.MediaTypeImageConfig { | ||
| // We could return at least the layers, but that’s already available in a better format via types.Image.LayerInfos. | ||
| if m.Config.MediaType != imgspecv1.MediaTypeImageConfig && m.Config.MediaType != manifest.WasmConfigMediaType { |
| imgspecv1.MediaTypeImageManifest, | ||
| imgspecv1.MediaTypeLayoutHeader, | ||
| ociencspec.MediaTypeLayerEnc, ociencspec.MediaTypeLayerGzipEnc: | ||
| ociencspec.MediaTypeLayerEnc, ociencspec.MediaTypeLayerGzipEnc, |
There was a problem hiding this comment.
This function is deprecated and has no known users, so I don’t see much point in extending it.
|
Also, for |
|
Hello @mtrmac, Thank you for your review. Background on our use case: We're working on running encrypted WASM modules inside Trusted Execution Environments (TEEs). I've published two reference images demonstrating this:
You can inspect these with: docker manifest inspect rodneydav/wasm-addition:latest
docker manifest inspect rodneydav/wasm-addition:encryptedWhile my encrypted image uses For our TEE use case, we need layer encryption support. Would it be acceptable to add WASM layer encryption or would you recommend a different approach for securing WASM artefacts? |
3 participants
Description
This PR adds comprehensive support for WebAssembly (WASM) OCI images to the container-libs image package, enabling WASM container images to be stored, distributed, and managed through the OCI registry ecosystem.
Changes
application/vnd.wasm.content.layer.v1andapplication/vnd.wasm.config.v1+json)Use Case
This change enables users to work with WASM container images using Podman, Buildah, Skopeo, and other tools in the containers ecosystem. WASM images can now be pulled, pushed, inspected, and managed just like traditional container images, integrating seamlessly with the existing crun-wasm runtime support for wasi/wasm platforms.