>From a scanning perspective, it might help that we added a Source descriptor to the OCI image specification manifest file to identify the location of the source code in the container image. If you're not familiar, OCI is the upstream container standardization project started by Docker, Red Hat, IBM, etc.
Through that URL someone should be able to obtain the license for the package. It would be much easier if they used the SPDX short identifiers. https://github.com/opencontainers/image-spec/pull/71/commits/88ef945196cc5d6b1e5249470fef752a06fa96e8 --- Mike Dolan VP of Strategic Programs The Linux Foundation Office: +1.330.460.3250 Cell: +1.440.552.5322 Skype: michaelkdolan [email protected] --- On Fri, Oct 7, 2016 at 4:15 AM, Yev Bronshteyn < [email protected]> wrote: > I would think an example with Docker – which is more cross-platform and > ubiquitous might be preferable, no? Additionally, the tutorial you included > would not demonstrate the creation of descendant images or the use of > external references to Docker hub or any other container registry. > > > > A more illustrative tutorial might be this: https://docs.docker.com/ > engine/getstarted/step_four/. Here, an image is taken from the Docker > hub. Then, a descendant image is built (DESCENDANT_OF relationship to the > source image) and an OSS package is added to that image (image package has > CONTAINS relationship to the fortunate package). Finally, a container is > created from the latter image (has a DESCENDANT_OF relationship to the > latter image). This is a perfect test case. > > > > Actually, this example raises another interesting question: the source > image pulled from the Docker hub is not one with a specific tag, but > latest. So how would this map to a packager versionInfo? If a container > is created from the descendant image a year after its descendent image is > created, it will certainly use a different version of the underlying Ubuntu > image than a container that’s created immediately after the descendent > image. So I think we need to establish a convention that for container > images, the absence of a package version should be assumed to correspond to > the latest version. The alternative would be to consider latest as a > version in and of itself, which seems like a horrible thing given the > fluidity of what the latest version actually is. > > > > > > > > > > *From: *Kate Stewart <[email protected]> > *Date: *Friday, October 7, 2016 at 2:27 AM > *To: *Yev Bronshteyn <[email protected]> > *Cc: *"[email protected]" <[email protected]> > *Subject: *Re: SPDX to describe containers? > > > > Hi Yev, > > Great topic for discussion and figuring out best practices for > relationships. :-) > > > > To make sure we figure this out properly, lets turn this into a > concrete example (ie. specific images and applications) > > and explore the relationships that way, rather than at the abstract level. > If we get it right, with specific names, > > we should then be able to take it to the abstract. You're started to go > this route with your ubuntu reference, > > so how about we take what's descibed on https://linuxcontainers. > org/lxc/getting-started/ and start mapping out what > > we agree as best practices for the relationships being described there? > > > > I know some of the developers, and when we've got it mapped out, we can > cross check our understanding matches > > theirs? > > > > Kate > > > > > > > > On Thu, Oct 6, 2016 at 5:06 PM, Yev Bronshteyn <ybronshteyn@ > blackducksoftware.com> wrote: > > 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? > > > > > > [image: id:[email protected]] > Yev Bronshteyn > Senior Software Engineer > E: [email protected] > blackducksoftware.com <https://www.blackducksoftware.com/> > > > > > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech > > > > > > -- > > Kate Stewart > > Sr. Director of Strategic Programs, The Linux Foundation > > Mobile: +1.512.657.3669 > > Email / Google Talk: [email protected] > > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech > >
_______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
