[00:00.000 --> 00:14.720]  Alright, good morning everyone. My name is Jan Simon Muller. I work on the Automotive
[00:14.720 --> 00:25.520]  Great Linux project and today I want to talk about how we produce our S-bombs or what we
[00:25.520 --> 00:37.560]  evaluated, what we did, what we learned and yeah, some lessons learned. If you want to
[00:37.560 --> 00:45.120]  reach me just find my email or find the AGL ISC channel or what not, there you can contact me.
[00:45.560 --> 00:57.520]  Okay, in a nutshell, AGL is an open source platform for different users in the car. We
[00:57.520 --> 01:04.680]  started with infotainment. We have also an instrument cluster profile, telematics profile
[01:04.680 --> 01:13.880]  and we are also working on software divine vehicle. There is a virtualization expert group
[01:13.880 --> 01:20.600]  and all of that. Code first so you can go to our website, you can download pre-built releases,
[01:20.600 --> 01:29.360]  you can clone the stuff, rebuild it, everything is there. And we built with the Yocto project,
[01:29.360 --> 01:37.760]  so we are essentially a collection of layers. Yocto plus some automotive software and tooling.
[01:37.760 --> 01:52.280]  So for S-bombs, things started around like three years ago when one of the member companies
[01:52.280 --> 02:02.600]  looked into how to generate S-bombs kind of early and they were looking for an in-house
[02:02.640 --> 02:10.320]  solution and they were basically developing that within AGL, presenting and doing stuff.
[02:10.320 --> 02:19.120]  We encouraged them to do that upstream, have a repo within AGL and out of that,
[02:19.120 --> 02:28.320]  we then told them, you know, that should actually go more upstream. So that ended up on
[02:28.560 --> 02:40.800]  git.yachtoproject.org and that's META SPDX scanner. So initially there was just one tool
[02:40.800 --> 02:53.920]  supported in there and that was upload to phosology. So they were looking into a combination of
[02:54.880 --> 03:05.120]  phosology and SW360. That's what they were evaluating and that basically gives you
[03:05.120 --> 03:15.040]  Yocto build, upload to phosology. Phosology will do the scanning and then later on you
[03:15.040 --> 03:29.360]  move the data into SW360. That was their plan. In principle, that's a post-mortem,
[03:29.360 --> 03:39.040]  that's a post-build approach. You take the sources that were exported from the build,
[03:39.040 --> 03:51.360]  the patched sources and then do analysis on it. All of that predates the now available
[03:51.360 --> 04:07.000]  Create SPDX in Yocto. So that was before that time. To make that work, you need to set up
[04:07.000 --> 04:15.240]  a phosology server. You need to upload the sources. It will then run, I think, five different
[04:15.240 --> 04:25.440]  scanners on it and then essentially you get the results for manual review and correction
[04:25.440 --> 04:33.080]  and whatnot. So you really need to sit down, inspect the result, make decisions on where
[04:33.080 --> 04:46.320]  the scanners are unsure and make a final verdict and then you can output the data, put it into
[04:46.320 --> 05:02.240]  other tooling. Meanwhile, there are at least three different tools supported in that layer.
[05:02.240 --> 05:10.400]  One is for Solotree, the other is CanCode and the third is an uploader for commercial
[05:10.400 --> 05:28.920]  tool. After that, later Joshua Hulthog right after me added support for exporting SPDX files
[05:28.920 --> 05:36.240]  right during the build from Yocto. So the difference is that this happens right at the
[05:36.240 --> 05:45.960]  build stage with all the data, metadata we know there and it does not require an external
[05:45.960 --> 05:57.200]  server. It uses the available metadata we have. So it's faster for us. It runs during
[05:57.200 --> 06:07.120]  the build and basically it's close to no additional resources consumed. We now have
[06:07.120 --> 06:15.920]  that enabled. So for our releases and the stuff, you'll find the SPDX files right next
[06:15.920 --> 06:30.000]  to the artifacts. Okay, great. What did we learn essentially? It depends now from an
[06:30.000 --> 06:39.160]  open source project versus in-house product and so on. For us, the Solotree approach or
[06:39.160 --> 06:46.760]  the approach with the scanner, I don't want to pick on one here, it required way more
[06:46.760 --> 07:00.400]  CPU resources. You need to shuffle all the source tower balls up and down. It requires
[07:00.400 --> 07:09.080]  manual review and that was for kind of for the open source project side. That was just
[07:09.080 --> 07:24.240]  too much, right? And actually we lost information once we went from the build to the external
[07:24.240 --> 07:35.360]  scanner. Basically, what does this belong to? Which build is this? Yes, you can partially
[07:35.360 --> 07:45.520]  solve that by folder naming and help out on that but you'll lose a connection here. On
[07:45.520 --> 07:56.760]  the other side, it depends on your requirements. If your legal department in the end says we
[07:56.760 --> 08:06.480]  have to scan, right? Because even if we get most of the artifacts from, let's say, supplier,
[08:06.480 --> 08:15.000]  we still add something, right? Or we need to know for sure, then you have to scan, period.
[08:15.000 --> 08:26.040]  And that's what actually happens for us. Our members, essentially, they have to scan
[08:26.040 --> 08:31.880]  because they add stuff on their own. So in the end, they have to scan their final stuff
[08:31.880 --> 08:47.120]  anyway, right? So for us, we took then the route to take the faster way. We take the
[08:47.120 --> 09:06.840]  analysis during the build and use that. And there is one basically thing that we have to
[09:06.840 --> 09:25.000]  solve at a more global level. The data we have and we provide, which we basically can
[09:25.000 --> 09:31.280]  say, okay, this is our sources that you consume. Does the legal department accept that and
[09:31.280 --> 09:42.640]  trust it? Or will they go ahead and say, we have inspected everything again? So that's
[09:42.640 --> 09:55.040]  a crucial point. Yeah, so right now, we are basically at the stage, all right, we can
[09:55.120 --> 10:04.760]  create the SPDX files. But how can I consume it? How can I present it? Basically, the
[10:04.760 --> 10:13.760]  S-bombs, it's relatively new in the end. So the tooling is still evolving. So the tooling
[10:13.760 --> 10:28.320]  is new. And for us, we are looking for how can we present this in a way that makes it
[10:28.320 --> 10:43.680]  easily consumable. Essentially, let's say for our CI purpose, we would like to know
[10:43.680 --> 10:55.880]  is there anything that was added that changed? So the diff is interesting. Yeah, that's an
[10:55.880 --> 11:02.400]  essential next step for us. All right, questions?
[11:02.400 --> 11:27.040]  So, Josh will detail that. Yes, so what information goes into the SPDX files here? Yeah, what
[11:28.000 --> 11:34.880]  that will come in the next talk. Yeah, so I don't want to steal Josh, the funder from Josh. He has it
[11:34.880 --> 11:42.400]  in his slides, I know. So I think your slide probably answers this. You're producing S-bombs,
[11:43.360 --> 11:47.680]  but you're not doing anything with them. So it's just basically, have I created a file?
[11:47.680 --> 11:54.240]  Yes. Yeah, right now, we are at the stage, okay, check, S-bombs created.
[11:57.040 --> 12:01.920]  Actually, I failed now a decision to say the build's not long. I've got to go back and change the
[12:01.920 --> 12:12.080]  build. Yeah, no, no, okay, no, no. So what are you doing differently to what you were doing before
[12:13.040 --> 12:22.000]  three years ago? We just do generating release notes. Yeah, yeah, so you're not so okay. Yeah,
[12:22.720 --> 12:31.280]  yeah. So, I mean, we are using the report tool. So we can basically ease and the
[12:31.280 --> 12:37.840]  diopto recipes. So we can easily say that's the diff in the recipes. So we changed this and this
[12:37.840 --> 12:43.840]  and this and that. But back then, no. Yeah.
[12:51.120 --> 12:51.920]  No, not yet.
[12:55.360 --> 13:01.680]  So there's two questions. How much of this code was used from the double open original project
[13:01.760 --> 13:08.000]  that was in the app too? This is the one that created the whole spdx generation on the app too.
[13:08.640 --> 13:14.560]  This is, I think this is the original code. Do you know? That's the question for Josh. Next talk.
[13:17.200 --> 13:21.760]  Why do you need the presentation visualization tool? Why are you reinventing the use if you already
[13:21.760 --> 13:30.880]  have a couple of tools already doing that? For presentation and presentation. Why are you working
[13:30.960 --> 13:39.600]  now? It would be the next step for us. So I'm not saying we develop this. Basically, we are looking
[13:39.600 --> 13:50.320]  now, start using what exists. I'm not saying we are reinventing the wheel. I'm going step by
[13:50.320 --> 13:57.840]  step. So I'm an, I'm an adopter. Yeah. So that's why I'll sit in and listen.
[14:02.480 --> 14:07.360]  As to the problem you mentioned before about the choice between
[14:08.080 --> 14:17.680]  using phosology review, we face the same problem in our project. And the way we solved it is to
[14:17.760 --> 14:25.600]  decouple the two processes. So you provide input for phosology with one more pipeline. Yeah. And then
[14:26.320 --> 14:33.680]  leave it, the only thing work. And then when the data is ready, you can import them in subsequently.
[14:33.680 --> 14:40.960]  Yeah. So the only way, because in this way you can provide input to the audit team so they can
[14:40.960 --> 14:47.280]  work timely before the release. Yes. And then you basically feed that back into, I mean, if you
[14:47.280 --> 14:54.560]  have a release build, right? For release builds, we have, we can. No, but we do that also from the
[14:54.560 --> 15:00.160]  time. Okay. Okay. Thank you very much. Thank you.