WEBVTT 00:00.000 --> 00:10.760 Next up, more traditional technologies. 00:10.760 --> 00:16.200 See you in the simplest class of both of us, we've come by our admin. 00:16.200 --> 00:29.600 Alright, so, as you all are aware, modern software is written in rust or whatever, but 00:29.600 --> 00:43.000 there's a lot of C still, and we've been talking about C projects all day, and one of the 00:43.000 --> 00:55.360 things that I keep hearing is, hey it would be nice if we had S-bomb data for C, so here we go. 00:55.360 --> 01:00.960 For those who don't know, I do not come from a computer science background. 01:00.960 --> 01:10.360 I got into open source, free software as kind of a hobby, turned into a career because 01:10.360 --> 01:16.240 I realized you can make a lot more money as a software engineer than doing any sort 01:16.240 --> 01:24.240 of empirical research, so that's fun if you want to talk to me about either software engineering 01:24.240 --> 01:28.400 or psychology, I'm always down. 01:28.400 --> 01:38.720 I've been working on Alpine since 2009, before that I worked on WN. 01:38.720 --> 01:45.720 I've done all sorts of stuff in Alpine, the X64 port, I've done a lot of Loonarch porting 01:45.720 --> 01:53.440 mostly because I found that fascinating. 01:53.440 --> 01:59.880 I maintain the G and U tool chain in Alpine, so GCC, B and U tools, all of that. 01:59.880 --> 02:07.440 The networking stack, I have up done in G, a lot of core U-tillies, Libu context, G-libc, 02:07.440 --> 02:10.200 compatibility, et cetera. 02:10.200 --> 02:16.160 I also started Alpine's security team in 2021. 02:16.200 --> 02:29.880 I needed a actual, like, cert-type team to help all of the people using Alpine in the world. 02:29.880 --> 02:38.400 We had, like, security data, but it wasn't very good, so I built out a security team 02:38.400 --> 02:46.120 as part of my work with the Google Open Source security team. 02:46.120 --> 02:55.880 My focus, largely, is on ensuring Alpine sticks around for the foreseeable future. 02:55.880 --> 03:06.440 There's a lot of conversations about that every year, because Linux distributions are hard. 03:06.480 --> 03:16.360 But mostly, I'm obsessed with how software is actually composed, how software gets stacked 03:16.360 --> 03:27.840 into different configurations and all of that, because it basically takes the billage to 03:27.840 --> 03:30.680 build all of this. 03:30.720 --> 03:36.840 Basically, it's that story that I've been trying to track for so long. 03:36.840 --> 03:45.680 So I'm on Macedon, and sometimes I'm blue sky, I also have a LinkedIn, but I hate LinkedIn. 03:45.680 --> 03:50.960 I hate everything LinkedIn represents, so I'm not linking it here. 03:50.960 --> 03:53.240 Why am I here? 03:53.320 --> 04:01.160 So last year at Boston, there was a talk about somebody who told us a story about how 04:01.160 --> 04:09.720 he struggled to build C and S-bomb spruce, C-make project, and how he had to port his entire 04:09.720 --> 04:16.520 project over to C-make, and he was not very happy with how things were going. 04:16.520 --> 04:26.360 So I've been working on this C-S-bomb problem, literally since 2021. 04:26.360 --> 04:31.240 It has been a long time to get to the point where we're at. 04:31.240 --> 04:40.200 This is largely because C and the model that S-bombs are built around, it's not really 100% 04:40.200 --> 04:42.520 shaped the way it is. 04:42.520 --> 04:50.360 So this talk is for you, Chris, I hope you enjoy it. 04:50.360 --> 04:54.840 Now that it's probably not very useful to you. 04:54.840 --> 05:05.200 So I could have seen C and C++ projects kind of predate the current model for how dependencies 05:05.200 --> 05:06.200 get distributed. 05:06.200 --> 05:13.720 Like if you go, you have go packages with rust, you have prates, and Java, you have 05:13.720 --> 05:20.080 Maven, JavaScript's closer, but Java has Maven so that doesn't, you know, that's more 05:20.080 --> 05:22.200 into modern direction. 05:22.200 --> 05:29.760 So with those tools, you just pick an S-bomb generator of your choice, point it out a 05:29.760 --> 05:36.000 lot, file, hit the button, you get a build time S-bomb. 05:36.000 --> 05:41.560 C and C++ have modules now, nobody cares about them. 05:41.560 --> 05:50.240 Well, some people care about them, but in the real, in the wild, they haven't been adopted 05:50.240 --> 05:55.000 yet, very widely. 05:55.000 --> 06:03.720 Libraries, traditional libraries, and SDKs maintain their dominance over modules. 06:03.720 --> 06:11.880 So there's no packages, no lock files, and dependency management, therefore exists elsewhere. 06:11.880 --> 06:14.080 Hello, I manage your dependencies. 06:14.080 --> 06:17.680 Well, I don't, but my code does. 06:17.680 --> 06:27.840 So this is package comp, I read, there's two SDK managers really for C and C++. 06:27.840 --> 06:34.080 There's C-make, which I'm sure all of you are familiar with, and many of you have probably 06:34.080 --> 06:43.480 cried or sworn at it, especially when it, you know, gives you confounding error messages 06:43.480 --> 06:45.160 and all of that. 06:45.160 --> 06:48.520 But some people seem to like C-make. 06:48.520 --> 06:54.920 It started its life as a project at the Department of Energy, so, you know, if it feels 06:54.920 --> 07:00.200 like you're dealing with the government when you're working with C-make, it's because 07:00.200 --> 07:03.800 you are. 07:03.800 --> 07:14.520 On the foot side, the known people made package config back in 1999. 07:14.520 --> 07:20.760 You might remember a long time ago, like, building software running config, you know, running 07:20.760 --> 07:27.760 to configure script, and then it would be like, you need to go download package config. 07:27.760 --> 07:32.980 That was a long time ago, now days, you get a package config implementation as part of 07:32.980 --> 07:37.440 your distribution provided tool chain. 07:37.440 --> 07:44.840 So what does package config do, and why do we care about it? 07:44.840 --> 07:50.040 Traditionally, when you use package config, you get a date, okay. 07:50.040 --> 07:59.440 So package config is a client in a way that accesses and manipulates a database about 07:59.440 --> 08:06.880 software dependencies, specifically SDKs. 08:06.880 --> 08:11.240 You query it as a form of constraints. 08:11.240 --> 08:15.440 The constraints must be satisfied. 08:15.480 --> 08:21.360 The constraints are also graphs that you then walk over. 08:21.360 --> 08:25.280 The original package config didn't strictly work that way. 08:25.280 --> 08:30.000 It was more of a brute force search. 08:30.000 --> 08:31.720 I hope everything works out. 08:31.720 --> 08:35.040 I hope you have all of your dependencies if not fail. 08:35.040 --> 08:37.520 Package config actually has a proper solver. 08:37.520 --> 08:40.440 That's the main difference. 08:40.440 --> 08:45.520 Typically every unix build system uses package config in some way. 08:45.520 --> 08:52.280 Automate has integration through the binnerable package.informacroset, which I'm now 08:52.280 --> 08:59.280 stuck maintaining, even though I don't know anything about maintaining informacroses. 08:59.280 --> 09:08.400 There's also a C-mate, which has a package config macro, and a mess in which it's kind 09:08.400 --> 09:14.200 of, or mason, I don't know how to pronounce it. 09:14.200 --> 09:19.640 That's the new kind of hotness in terms of replacing like automate. 09:19.640 --> 09:25.680 Basically they look at C-mate and wait, hey, there's a lot of cool ideas here, but C-mate 09:25.680 --> 09:30.600 is unpleasant to use, so we're going to make our own. 09:30.600 --> 09:32.040 So they did. 09:32.120 --> 09:41.880 So with package config, you ask it for certain data, and then it calculates a solution based 09:41.880 --> 09:44.800 on your query and it gives you back compiler flags. 09:44.800 --> 09:47.800 That's the traditional use. 09:47.800 --> 09:54.280 There are also other functions that have been added since then, such as key value storage 09:54.360 --> 10:02.800 and a whole bunch of other things, although it's baked onto this one binary package 10:02.800 --> 10:07.440 config, it's a horrid interface, but we're kind of stuck with it. 10:07.440 --> 10:17.720 So package comp however has additional tools, which are useful for S-bombs. 10:17.720 --> 10:21.840 We have two different S-bombs, generators in fact. 10:21.840 --> 10:35.520 There is BOM tool, that's the one that I wrote in 2022, and it generates an S-PDX 2.3 S-bombs. 10:35.520 --> 10:41.800 In package config get today, we also have an S-PDX 3 generator, which is presently a work 10:41.800 --> 10:48.960 in progress, well, technically it's an S-PDX 3.0 light generator. 10:48.960 --> 10:56.440 But you get the JSON out the S-bombs, and you can do cool JSON out the stuff with them. 10:56.440 --> 11:05.960 The other main thing that you get is the package comp, directed graph output tool, which 11:05.960 --> 11:13.520 you can fit, which you can fit into graph is dot utility, and that allows you to visualize 11:13.520 --> 11:17.920 your actual dependency set, which is very useful. 11:17.920 --> 11:27.480 So how does this apply to an actual application, like, say you want to build a C program, 11:27.480 --> 11:34.560 or a C++ program, like some sort of calendar app, or whatever, with GTK, or something 11:34.560 --> 11:35.560 with QT. 11:35.560 --> 11:38.680 How do you do it? 11:38.680 --> 11:46.880 So the easiest way is you ask your build system, like me-son, I'm just going to call it me-son, 11:46.880 --> 11:49.280 because that's what I normally call it. 11:49.280 --> 11:54.960 Yes, me-son, to build you a PC file that describes your project. 11:54.960 --> 12:06.720 That's very similar to what would be considered a lock file, and another language ecosystem, 12:06.720 --> 12:14.160 because you have your directed set of constraints, and then you can use that data to build 12:14.160 --> 12:16.480 an S-bombs. 12:16.480 --> 12:20.760 Once you have your PC file for your app, and you don't have to install it, we have this 12:20.760 --> 12:25.440 whole concept called uninstalled PC files, it's a whole thing. 12:25.440 --> 12:29.720 If you want to know about it, it's incredibly cursed, just catch me in the hallway. 12:29.720 --> 12:38.400 But you take this PC file, and you analyze it with one of the aforementioned tools, and then 12:38.400 --> 12:43.760 you get an S-bom, or graph is document or whatever. 12:43.760 --> 12:48.640 So now it's demo time. 12:48.640 --> 12:57.320 If you saw I had a console window that I dragged over, and so we're going to take a look at 12:57.320 --> 13:02.080 what we can do, and then we're going to talk about the next steps. 13:02.080 --> 13:05.680 So let's see if I can do that real quick. 13:05.680 --> 13:20.640 So far, the demo gods seem to be cooperating, but you never know, oh, no. 13:20.640 --> 13:40.400 So we're going to do a build real quick. 13:40.400 --> 13:46.880 I don't remember if I cleaned it first, so I'm going to just do that real quick. 13:46.880 --> 13:53.800 So we're building a very simple application here. 13:53.800 --> 14:00.800 This is just a hello world application to show you that this is in fact a real application. 14:00.800 --> 14:06.000 I will run it. 14:06.000 --> 14:10.200 It went to the wrong screen. 14:10.200 --> 14:20.280 But no, there it is. 14:20.280 --> 14:25.480 Anyway, this is just a GTK for application. 14:25.480 --> 14:37.960 But if you notice, we have an SPDX2 S-bom, and an SPDX3 S-bom, and then we also have our dependency 14:37.960 --> 14:48.200 graph, which I do some editing said to make it more friendly to show on a big screen. 14:48.200 --> 14:59.840 So if we, I actually have that dependency graph, I actually opened this, so if I can move 14:59.840 --> 15:12.840 it over here, you can't, there. 15:12.840 --> 15:21.000 You know, I used to say, I used to tell people use KDE when you're presenting, but 15:21.000 --> 15:26.000 there's my mouse. 15:26.000 --> 15:40.240 Okay, so up here, we have the hello world app, and we directly pull in GTK, which depends 15:40.240 --> 15:46.000 on Pango, which is the known text library. 15:46.000 --> 15:52.720 Technically that's Pango Cairo, which depends on Pango, which depends on Harfbuzz, which 15:52.720 --> 15:56.320 depends on GDPXBuff, blah, blah, blah, blah. 15:56.320 --> 16:03.600 So we can scroll through and visualize this whole thing, and that's a lot of dependencies, 16:03.600 --> 16:06.800 right, for a simple hello world desktop app. 16:06.880 --> 16:12.520 In fact, we have Vulcan in here, which means that we're doing stuff with GPUs, just a render 16:12.520 --> 16:17.200 hello world, basically. 16:17.200 --> 16:22.720 So we keep going, it depends on G-lip, because everything, in the known world, depends 16:22.720 --> 16:26.480 on G-lip, so as you can see, there's tons and tons and tons and tons and tons and tons 16:26.480 --> 16:29.240 and tons of paths pointing to G-lip. 16:29.240 --> 16:35.720 And then we have U-tilinic stuff over here, and more U-tilinic stuff over here, and 16:35.720 --> 16:43.960 we have Z-lip, and anyway, so the interesting thing is package comp actually can figure 16:43.960 --> 16:48.640 out what is a direct dependency versus an indirect dependency. 16:48.640 --> 16:59.120 And that's very important when it comes to vulnerability management, because as other 16:59.200 --> 17:05.360 people alluded in earlier presentations, like the Zephyr person, for example, you can have 17:05.360 --> 17:15.680 a CVE in a package, and maybe that's a problem, maybe it's not a problem, you know, people 17:15.680 --> 17:21.040 struggle to reason about that, which is why there's apparently an entire industry now selling 17:21.040 --> 17:27.720 zero CVE images in various forms. 17:27.720 --> 17:35.720 I think all of those products missed a point, though, because what really matters is, is 17:35.720 --> 17:38.400 that vulnerability reachable or not. 17:38.400 --> 17:47.040 So my GTK for hello world app that I demonstrated a moment ago, which was not vib coded. 17:47.040 --> 17:54.360 I just googled it and typed it out. 17:54.360 --> 18:02.000 That application has an indirect dependency on Z-lip, but it's an indirect dependency. 18:02.000 --> 18:07.760 So there's a CVE in Z-lip, it probably doesn't actually matter in practice, because there's 18:07.760 --> 18:10.160 no rectipinancy. 18:10.160 --> 18:19.360 So we're running short on time, so I'm going to go back to the slides, because I have 18:19.360 --> 18:31.200 a couple more slides, just a few more, and, oh God damn it, all right, so let's talk 18:31.200 --> 18:42.200 about what we need to do, but actually hold on. 18:42.200 --> 18:47.600 Just to show that these as bombs are real, I'm going to show that they're real. 18:47.600 --> 18:59.200 Somehow, there, okay, so we can use the Kubernetes, do document outline on the hello 18:59.200 --> 19:14.960 bus, then voila, CES bomb, okay, so now we will go back to the slides, which it, yeah, 19:14.960 --> 19:23.320 thank you computers, I hate them. 19:23.320 --> 19:31.400 So there's a few things we need to do, quality of life improvements are important. 19:31.400 --> 19:39.040 Right now, with Nissan and Automate, you have to stitch everything together yourself to 19:39.040 --> 19:52.360 get these SPDX S-bombs as build output, and we need more data in the package-config files, 19:52.360 --> 19:55.840 and that will yield higher quality S-bombs. 19:55.840 --> 20:00.280 You have your SPDX S-bombs quality score tool, and right now we have a valid S-bombs, but 20:00.280 --> 20:07.640 it would score like, you know, 4.0 or something, we want to score, you know, 8, 9, 10 on 20:07.640 --> 20:08.640 it. 20:08.640 --> 20:16.560 So we need more data in the PC files to do that, also because, at least in my experience, 20:16.560 --> 20:23.640 there's some sort of ongoing, holy war about S-bomb formats, we probably want to have 20:23.640 --> 20:38.520 a cyclone DX format building tool thing, and we need also to support package URLs. 20:38.520 --> 20:43.800 So, you know, like I was saying, build system integration, the best way to get more S-bombs 20:43.800 --> 20:49.200 is that you don't have to think about S-bombs, and like I was saying, that requires 20:49.200 --> 20:57.080 Nissan and Automate to support it, see make already has a solution here, that was demonstrated 20:57.080 --> 21:02.160 during the S-bombs. 21:02.160 --> 21:09.000 This is kind of my thinking about how we can make Automate do S-bombs really easily, you 21:09.000 --> 21:14.400 can just ask it to generate an S-bombs based on a PC file. 21:14.400 --> 21:23.720 I have a patch that I'm about to submit to GNU to get that done. 21:23.720 --> 21:28.560 Obviously, you still have to compose the PC file and all of that. 21:28.560 --> 21:33.200 With Nissan, it's going to be a little bit more slick because Nissan already knows everything 21:33.200 --> 21:40.200 that it needs to know in order to build an S-bomb out anyway. 21:40.200 --> 21:47.880 So, essentially there what we're going to do is re-work the package config module to return 21:47.880 --> 21:53.120 a specific package config object that represents the package config resource, and then you 21:53.120 --> 21:58.520 can do stuff with it so you have your PC file that you generated, it's a package.generate 21:58.520 --> 22:03.400 B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B-B, and then you can take that PC file 22:03.400 --> 22:08.840 interim output and then render an S-PDX or whatever from it. 22:08.840 --> 22:12.780 And it will use the right tool under the hood to get it done. 22:12.780 --> 22:18.120 So we 놓 the logo, so we're talking in IRC about that, and of course anybody interested 22:18.120 --> 22:23.360 can find me while we're still doing this Fosstum Thing. 22:23.360 --> 22:27.820 Let's talk about S-b-DX metadata. 22:27.820 --> 22:33.900 farters for additional fields, although after watching all of y'all, it's wonderful 22:33.900 --> 22:39.180 talks. I've thought of about 10 more that I need to add. 22:39.180 --> 22:40.180 What? 22:40.180 --> 22:43.740 If there's three fields that you need that are missing, let us know first. 22:43.740 --> 22:50.020 Well, fields I need to add to PC files. 22:50.020 --> 22:56.740 So anyway, these are the four that are like super critical because if you can, if we can 22:56.740 --> 23:06.740 add these to everything, the S-bombs that we generate with the S-bomq, and as soon as we 23:06.740 --> 23:12.740 can get these changes into M-s on and all of that, I think we'll be in really good shape. 23:12.740 --> 23:23.740 Please use these fields to improve your S-bomq minutes left. Package URLs are really fun when 23:23.740 --> 23:29.140 it comes to package config because we're not describing a package, but we're also kind of 23:29.140 --> 23:36.740 describing a package because it's in the name, right? Package config. 23:36.740 --> 23:47.980 But the problem is, these are an intermediary package. It's an S-d-k. So we need to be able 23:47.980 --> 23:56.980 to identify that this is the GTK4 SDK that came from Alpine or Debian or whatever. 23:56.980 --> 24:02.020 So we need like a compound form of a package URL, basically, where we can be like this 24:02.020 --> 24:09.380 is an SDK, and it came from here in this other package URL. 24:09.380 --> 24:15.580 It's first, I have some thoughts, but we need that. 24:15.580 --> 24:25.580 Cyclone DX, we need that because, again, we need that. People want it. 24:25.580 --> 24:34.580 And thanks to everybody on that list because they've either given the package config 24:34.580 --> 24:43.580 project money or they have paid me to work on this. Also, thanks to Tuka Passenen, I think 24:43.580 --> 24:51.580 I got that right. He wrote the first version of SPDX tool, and we're presently in the 24:51.580 --> 24:55.580 process of beating it into shape and getting it production ready. 24:55.580 --> 25:03.580 And thanks to all of you for hopefully adding these PC fields and to all of your projects 25:03.580 --> 25:10.580 in making SPDX and CNOT suck.