|
|
Subscribe / Log in / New account

An update on compliance for containers

An update on compliance for containers

Posted Apr 18, 2019 11:34 UTC (Thu) by cyphar (subscriber, #110703)
In reply to: An update on compliance for containers by pj
Parent article: An update on compliance for containers

> I suspect what you mean is they can't store a BOM _in any kind of standard way_.

Well, I said there wasn't an "easy way". There also doesn't happen to be a "standard way" but that's less of an issue if you can't even store it properly. Your suggestion appears to be to put the BOM in the layer data itself but I don't feel that's the best idea in the world -- BOM should be metadata (otherwise you're now talking about parsing the layer tar archives of an image in order to get BOM metadata). Not to mention you'd add even more magic files (.wh.* was enough of a pain, personally).

For an OCI image if you wanted to store BOM as metadata you'd need to store it in an annotation, but annotations aren't descriptors (typed pointers) in OCI which means that almost no client would actually be able to get the relevant data (and even if they could, you wouldn't get the same safety benefits of descriptors). In addition, the layering element is a problem (yet again[1]) because it means that you will have a BOM for each layer when really you'd want a BOM for the runtime rootfs you are actually going to be executing.

I believe all of this can be fixed with the right improvements to the spec, and I hope I can work on improving it in OCIv2.

[1]: https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds