Hi, all, After the bake-off, I got to thinking: it could be a very strong selling point if SPDX could be used to describe containers. I’d like to write up the idea as a blog post and, perhaps, a candidate for best practices, but first I wanted to check if anyone here had any objections to the following approach.
There are two packages describing a container – the CONTAINER package and the CONTAINER_IMAGE package. Their relationships are as follows. · DESCENDANT_OF to the package documenting the container image. The image package may, but does not have to have the ANCESTOR_OF relationship to the container package · CONTAINS to every other package deployed on the container. Packages deployed to the container can, but do not have to, have a CONTAINED_BY to the container package. · If SPDXRef-CONTAINER_IMAGE_B is created by building a container from SPDXRef-CONTAINER_IMAGE_A, making changes, and saving it as a new image, then SPDXRef-CONTAINER_IMAGE_B has a DESCENDANT_OF relationship to SPDXRef-CONTAINER_IMAGE_A, and SPDXRef-CONTAINER_IMAGE_A may, but doesn’t have to, have an ANCESTOR_OF relationship to SPDXRef-CONTAINER_IMAGE_B. Additionally, if the image from which the container is built is found on Docker hub, the image package would have the following external reference: Category: OTHER Type: https://hub.docker.com Identifier: name:tag, e.g. ubuntu:16.10 Lastly, there’s a question is how do we identify a package or a container as such. One way, staying within the current spec, is to give them more specific SPDX identifiers. So a container package would be SPDXRef-CONTAINER-MyUbuntuContainer. The container image package that it would reference would be SPDXRef-CONTAINER_IMAGE_Ubuntu_16_10 (which, hopefully, would be in an SPDX document Canonical would publish together with its container). I don’t believe we should add any additional spec constructs to support containers, because we don’t want to establish the practice of growing the spec for every hot new way to bundle software or maintain another Appendix/list of package types. And, since we’re trying to get distribution vendors to adopt SPDX and many produce container images for their distros, it might make sense to work out this story well before we rev another version of the spec. Thoughts? [cid:[email protected]] Yev Bronshteyn Senior Software Engineer E: [email protected]<mailto:[email protected]> blackducksoftware.com<https://www.blackducksoftware.com/>
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
