On Mon, Jun 17, 2024 at 11:17 AM Allan Elkaim via lists.yoctoproject.org <allan.elkaim=gmail....@lists.yoctoproject.org> wrote: > > Hello, > > I am trying to generate an SBOM using Yocto, but I am having issues > exploiting the result and could really use a hand. > > I have done the following steps on a "blank" poky repository on the scarthgap > branch: > > git clone git://git.yoctoproject.org/poky > > cd poky > > git checkout origin/scarthgap -b my-branch > > source oe-init-build-env > > I have then edited my local.conf to include those changes: > > INHERIT += "create-spdx" > SPDX_PRETTY = "1" > > > And finally, I compiled the core-image-minimal image for the default > qemux86-64 image. > > bitbake core-image-minimal > > Once everything is built, I have the following file: > > poky/build/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.spdx.tar.zst > > From here, I'm confused about how to exploit this archive, there are many > files in it and I do not understand why some of them seems to be named after > the name of the software "component" and other start with "recipe".
Yes, this is a bit of an unfortunate situation with SPDX 2.2 where we have to do some non-optimal things in order to generate meaningful output. Some of those non-optimal things are extraneous to the spec (but we try to make sure we aren't in direct violation of the spec). One of these is the entire concept of the "tarball of file", which requires some extra handling. Navigating the multiple documents can seem tricky, but it's actually not too bad. The key is the index.json file that is added to the archive. This file will give you the filename where each `documentNamespace` can be found in the archive. As you are navigating around a file, you'll come across references to objects that are outside of the current document, which will be some string that looks like: "DocumentRef-dependency-<SOMENAME>:<SOMESPDXID>". In the current document, you'll find a `ExternalDocumentRef` that maps the "DocumentRef-..." prefix to the `documentNamespace`. Once you have the `documentNamespace`, you can find it in the index.json file, and in that file you will find <SOMESPDXID>. Hopefully that all makes sense. The "recipe" files describe the recipe (e.g. the source code and how it was built), whereas the others describe the packages (e.g. the output files/binaries/etc.) built from that recipe. There is a GENERATED_FROM relationship that links the packages back to their recipe. > > I mainly am interested in establishing the list of software "packages" > (binary / libraries...) , along with their "owner" and their license. > > For instance, if I had dropbear embedded in my image, I would like to extract > the following information: > > PACKAGE : dropbear > VERSION: 2022.83 > LICENSE: MIT > SOURCE SITE: https://matt.ucc.asn.au/dropbear/releases > OWNER: Matt Johnston <m...@ucc.asn.au> Right, so you would start with the dropbear.spdx.json file. Some of what you are looking for can be found there, otherwise you'll need to follow GENERATED_FROM back to the recipe (using the algorithm described above) to find the rest > > Also, if possible, having the ability to produce some sort of dependency tree > would be really helpful. GENERATED_FROM will tell you what recipe(s) are built into a package. Once you have the recipes, BUILD_DEPENDENCY_ON will give you the build dependency tree. Following those recursively will give you the entire dependency tree for a given starting package. It will likely be large since we include the -native dependencies also :) If you want the runtime dependencies instead of the build dependencies, it's a little tricker. For each package file (e.g. "dropbear.spdx.json") there is a "runtime-" spdx file (e.g. "runtime-dropbear.spdx.json") that creates the RUNTIME_DEPENDENCY_OF relationships for the package. These have to be in a separate file because of circular runtime dependencies. Following these relationships will give you the web (it's not a tree or a DAG, so watch out) of runtime dependencies for a package. Hopefully all of the descriptions will shed some light on the relationship diagram I've included in my talks :) > > Do you have any tips / or leads on how to achieve those goals from the > produced core-image-minimal-qemux86-64.rootfs.spdx.tar.zst file ? > > I thank you very much in advance for your help and wish you a nice day ! > > Regards, > > Allan ELKAIM. > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63355): https://lists.yoctoproject.org/g/yocto/message/63355 Mute This Topic: https://lists.yoctoproject.org/mt/106725192/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
