WEBVTT 00:00.000 --> 00:12.680 Hi everybody, so I'd slid it over. Welcome to Struggles with Making Esperance for 00:12.680 --> 00:21.480 Sea Applications. So if I use a modern language and I'm illustrating here with Dart, then 00:21.480 --> 00:27.560 things are easy. I can just take a lock file that I've used against my package manager and 00:27.560 --> 00:32.960 throw it into a tool like sift or trippy, and it's going to generate an s-bomb for 00:32.960 --> 00:37.640 me. Are you okay? 00:37.640 --> 00:47.800 So just about any modern language using a package manager is going to generate a lock file 00:47.800 --> 00:53.760 and I can take that lock file and put it into one of those tools and I've got a generated 00:53.760 --> 00:59.320 s-bomb. That might just be a starting point for an actual good quality s-bomb, but it's 00:59.320 --> 01:08.760 a good starting point. Now the problem with sea is I don't get a lock file and it's 01:08.760 --> 01:17.080 a huge problem because sea is a mountain of code out there. So penis 2 all did an excellent 01:17.080 --> 01:26.260 presentation at EMF camp last year. You can find that presentation on the CCC website. 01:26.260 --> 01:31.840 He was talking about Cherry and Morello and the problem with legacy code bases and the fact 01:31.840 --> 01:38.760 that so much of it is unsafe languages. And so there you are. As of today, just about 01:38.760 --> 01:44.720 six and a half billion lines of open source sea, two and a quarter billion lines of sea 01:44.720 --> 01:51.520 plus plus. And if we compare that to rust, rust is only 57 million lines. So some of you 01:51.520 --> 01:55.920 would have seen Daniel Stenberg talking yesterday about when's curl going to be rewritten 01:55.920 --> 02:04.080 in rust and his answer is never. So hi, I'm Chris. I'm an engineer at a company called 02:04.080 --> 02:10.520 that sign. We build a platform for inter-end encryption and some zero trust net working tools 02:10.520 --> 02:16.480 on top of that platform. Our customers care about security. So how do we show them 02:16.480 --> 02:25.000 that we care about security? Well, I talk about a trifecta of security visualization. 02:25.000 --> 02:33.080 So we adopted open SSF scorecards first. Then we started producing S-bombs and doing salsa 02:33.080 --> 02:38.080 for our builds. And so everything that we're doing, we try and have that trifecta of 02:38.080 --> 02:44.280 scorecard, salsa, and S-bombs. Last year, one of our customers said, we love what you're 02:44.280 --> 02:52.840 doing, but we'd like your thing to run on an open WRT router with a MIPS chip set and just put 02:52.840 --> 02:58.960 it into two megs of flash. That's our limit. And so that was not going to support the 02:58.960 --> 03:05.760 dart demon that we build at the moment. And I looked at rust and rust wasn't actually going 03:05.760 --> 03:12.040 to give me a binary that was small enough. And so we've had to rewrite it in C. As we've 03:12.040 --> 03:17.360 been building this C stuff, I want to produce S-bombs. And so this is a journey through 03:17.360 --> 03:24.480 how I fail to actually produce S-bombs for our C binary. So I'm going to talk about things 03:24.480 --> 03:29.040 I've tried and found wanting. I'm going to talk about some things that I've come across 03:29.040 --> 03:37.240 that show promise of a way ahead for C-based ecosystems. I think in the long run, the 03:37.240 --> 03:43.720 Linux distributions are going to kind of solve the peredow 80% of this problem for us. And I 03:43.720 --> 03:51.280 also think C-make should probably be the focus of our efforts for resolving that residue. 03:51.280 --> 03:55.920 And then there's going to be a lot of long-tale to worry about in that. What was it eight 03:56.080 --> 04:02.320 three quarter billion lines of legacy code that's out there? So how not to make an S-bombs 04:02.320 --> 04:07.440 for a C project? The first thing I found out there was a thing called C-make S-bombs. And since 04:07.440 --> 04:13.200 I was using C-make to build the binary, this looked like it would be very promising. C-make 04:13.200 --> 04:20.560 S-bombs will help me with my NTIA boilerplate. So I can say who I am and what it is. And it 04:20.560 --> 04:26.880 doesn't do anything at all to address dependencies. My dependencies are pretty simple. So I use 04:26.880 --> 04:33.600 embed TLS, C-Json and UUID. So I could probably do this manually and I guess some people might 04:33.600 --> 04:40.080 even be trying to do that. But I'd really like something that's using my C-make declarations 04:40.080 --> 04:48.640 of my dependencies and generating based upon that. It's also S-pdx only for those who care 04:48.720 --> 04:56.160 about being bilingual in their S-bombs. At this point I had a chat with Ryan where and Ryan 04:56.160 --> 05:02.080 somebody who's very involved in OpenSSF stuff will be familiar to a bunch of people in this room. 05:02.800 --> 05:09.280 I'd been talking to Ryan about scorecardy things. I said, hey Ryan, like what are you doing at Intel 05:09.280 --> 05:16.320 to generate S-bombs for C? And he was like, oh, I'm glad you asked. We're doing a ton of stuff, 05:17.040 --> 05:25.680 but none of it's really kind of baked yet. Have you considered Conan? I had not. I'd never 05:25.680 --> 05:31.840 even heard of Conan. So I went and looked at Conan. And so Conan is a package manager for C and C++. 05:31.840 --> 05:38.000 So it should solve this problem of giving me a lock file. And it also has many of the popular 05:38.000 --> 05:45.360 dependencies already packaged. So my lead developer on the C rights for the demon was like, yeah, 05:45.440 --> 05:49.680 I took a look at Conan. It seems to have all of the things that we use there already. Maybe we should adopt this. 05:50.480 --> 05:58.880 I then created some trivial applications to test Conan.lock and through that into sift and got 05:58.880 --> 06:07.280 absolute garbage at the other side of it. And so the CFEs describing them as incomplete is probably 06:07.360 --> 06:15.040 saying more than with actually there. The other challenge I found with Conan is it's got excellent 06:15.040 --> 06:22.480 documentation for version one. And everybody's moved over to version two. And so I'm imagining 06:22.480 --> 06:27.120 those people were kind of involved in writing version two because there's no documentation there for 06:27.120 --> 06:33.200 newer doctors like me. So it's kind of hard to get into in a little bit frustrating at the moment. 06:33.280 --> 06:39.600 I think I'd like to like Conan, but it hasn't made made it easy for me to get into. And also, 06:40.480 --> 06:47.360 the tools aren't generating good espons from those lock files yet. So the next thing on my journey 06:47.360 --> 06:55.680 was an Intel tool, CV Bintool. And this scan's binaries. So I don't need to integrate it into my 06:55.680 --> 07:01.840 tool chain. I can just build my binary through it at CV Bintool and it'll tell me what's inside. 07:02.720 --> 07:12.160 Yeah, right. So CV Bintool has limited dependency recognition. So my trivial demo app that I was doing, 07:12.160 --> 07:19.360 it would find Z-lib in that. And it also gives me a false positive on that Z-lib because the Z-lib 07:19.360 --> 07:25.600 was actually a patched one from an Ubuntu distribution. But it was telling me about all of the CVEs 07:25.680 --> 07:31.440 associated with the un-patched version of that Z-lib. So not very confident in spiring. 07:34.400 --> 07:38.480 I do a podcast with a guy called Nick Selby and he used to work for trailer bits. 07:38.480 --> 07:43.920 I bet there's somebody from trailer bits in here in the room as well. And they have a tool called 07:43.920 --> 07:49.360 It Depends. And I'd heard Nick talking about this and actually we've heard this word. 07:50.240 --> 07:55.120 These words so many times today already. It depends. Well, there's a tool called it depends. 07:56.160 --> 08:04.880 And it claims to support CMake projects. And it also now has Cyclone DX support in the December 08:04.880 --> 08:13.120 24 release after three years of laying follow. And I threw it at my CMake project and I got nothing. 08:13.840 --> 08:20.000 And it just doesn't empty return. There's been an open GitHub issue about that since February 08:20.000 --> 08:27.120 22. And the project appeared to be abandoned when I was doing this in the middle of last year. 08:28.160 --> 08:33.600 And there seems to have been a flurry of activity in December. So I'm getting somebody's thrown 08:33.600 --> 08:40.000 a bunch of money at trailer bits. I'm loving it here. What's been going on there? 08:40.960 --> 08:45.200 I don't have an inside track on trailer bits anymore. So I don't know what's going on. 08:45.200 --> 08:53.680 But they're coin-operated, I guess. And the contract had run out. And then it seems somebody's 08:53.680 --> 08:59.920 found an interest in it again. And activity is happening. So some rays of hope. 09:03.840 --> 09:09.600 Victor, selling the second row there does sort of co-chairing of one of the Caesar 09:09.600 --> 09:15.600 working groups. He got together a group of people recently to talk about this challenge of 09:15.600 --> 09:21.680 C. S. Bombs. And somebody from the yokto project came along and talked about what they're doing. 09:22.560 --> 09:29.120 So yokto is a meta-distribution. It is a thing that lets you create your own Linux distributions. 09:29.120 --> 09:34.960 Very popular in the embedded world, especially things like automotive. We do actually have some 09:35.040 --> 09:39.520 of our customers asking for yokto stuff. So I've been poking my head into it a little bit. 09:40.320 --> 09:46.960 And yokto, because it is essentially a distribution and package manager, knows everything about 09:46.960 --> 09:53.040 what you've got there and can generate an S. Bombs in SPDX format, which is kind of nice and cool. 09:55.040 --> 10:01.200 There is some concern there that the generated SPDX can actually be bigger than the image 10:01.760 --> 10:09.600 that you're going to put onto your device. But it kind of illustrates that if you're a distribution 10:09.600 --> 10:14.880 with a package manager, then you've got all of the metadata that you need. And their story 10:14.880 --> 10:19.920 was basically they wrote a Python script to mangled the metadata and then now able to spit out 10:19.920 --> 10:30.800 SPDX, which is nice. And similarly Zephyr, so we heard about the equivalent Apache project 10:31.200 --> 10:39.680 a little earlier. Zephyr is another way of building things for small embedded systems. And again, 10:39.680 --> 10:47.920 they've got that similar view of end-to-end what's being built. And so that gives them all of the 10:47.920 --> 10:56.800 appropriate metadata that can be reformatted into an S. Bombs. So what's going to happen next then? 10:56.800 --> 11:05.040 Well, I'm actually really surprised that Vedha in particular is not shipping S. Bombs for 11:05.040 --> 11:09.520 Rell, because I'd have thought in response to the executive order, there would have been. 11:12.080 --> 11:13.360 They are. Since when? 11:16.560 --> 11:17.360 Okay. So. 11:18.160 --> 11:19.920 Yeah, but it's more than a year. 11:20.560 --> 11:21.440 Yeah, there are many things. 11:21.440 --> 11:24.240 There's been a while, yeah. Sorry, go ahead. 11:25.200 --> 11:30.800 So I'm expecting the mainstream Linux distributions to start shipping S. Bombs. It sounds like the 11:30.800 --> 11:39.280 secret Rell ones, if you press the right contract buttons, I'm guessing. But we want Linux to be open. 11:40.800 --> 11:46.800 And so I'm hopeful that the mainstream distributions are on the cusp of using their package 11:46.800 --> 11:53.760 managers and the metadata that they already have to start generating S. Bombs and giving them to us, 11:53.760 --> 12:00.960 so that we can make use of that. And I think for a lot of that, see package surface area, 12:00.960 --> 12:06.080 it's going to be used in the context of a Linux distribution and the packages that we're installing 12:06.080 --> 12:10.160 from that. And so it's going to solve probably about 80% of the problem. 12:12.560 --> 12:16.560 So what about the other 20%. Well, I think of the other 20% 12:16.720 --> 12:25.600 and see make has pretty much taken over the build processes of modern C applications. 12:26.320 --> 12:30.560 And see make gives us a way to express dependencies. 12:31.520 --> 12:37.200 And so if it gives us a way to express dependencies, it should also be relatively straightforward 12:37.200 --> 12:41.680 to give us a way to express those dependencies into an S. Bombs artifact. 12:42.640 --> 12:48.080 The problem that we get here is, I came across a brilliant article recently, which was talking 12:48.080 --> 12:54.080 about what it called the make file problem as a different way of describing cargo culting. 12:54.640 --> 12:58.560 And who in this room considers themselves as C make expert? 13:00.400 --> 13:06.880 That's more hands than I expected to see. Absolutely wonderful. And that's we've got a room of 13:06.960 --> 13:13.040 top class experts at Phos Deb. Just about all the times when I'm talking to people in tech, 13:13.040 --> 13:16.480 and I say, do you consider yourself a C make expert? They're like, no, not me. 13:17.600 --> 13:23.520 Because most of the C make that's out there is kind of copy-pastored from other C make. 13:24.240 --> 13:31.520 And hardly anybody actually understands what's going on with it. And it's challenging. And so 13:31.600 --> 13:42.320 I feel like the expertise to create S Bombs from C make isn't yet kind of focused enough on the problem. 13:45.600 --> 13:52.000 So in review then, I kicked the tires on a whole bunch of tools and they didn't make me happy. 13:55.600 --> 13:58.800 There's chances of improving all of these things. 13:59.120 --> 14:05.120 This is a lot easier if you've got a package manager. And so in the case of things like 14:05.120 --> 14:12.960 Yokto and Zepha, they are essentially package managers. And so they can actually generate S Bombs for us. 14:14.000 --> 14:20.240 I think mainstream Linux distros are going to solve the 80% of the problem. 14:20.960 --> 14:28.080 And I think C make should probably be our focus as a community for the rest of the residue of that 14:28.160 --> 14:34.160 problem or it's the first priority of that residue. There will of course be lots of 14:34.160 --> 14:41.040 long-tailed worry about all of the, you know, or how stuff that's out there, for instance that's 14:41.040 --> 14:48.080 not even using C make. And, you know, it's going to be an iterative process and I think it's going 14:48.080 --> 14:57.600 to take time. A couple of resource links, Victor, you know, got me to do a guest post on his 14:57.600 --> 15:03.200 S Bomify blog, a little while back, which is sort of the blog version of the talk that you've just heard. 15:04.080 --> 15:10.800 And the Yokto documentation is excellent. So there's a whole section now in their documentation 15:10.800 --> 15:19.600 about Yokto, about S Bombs from Yokto. Thank you very much for your time. You can email me 15:20.480 --> 15:27.600 at atsign.com or find me on socials at CPS1. And I've got a few minutes for questions I have. 15:27.600 --> 15:35.520 Yeah, really, really, really good presentation. I'm 13 to say. But about Yokto, so 15:35.520 --> 15:40.960 Yokto produces an S Bombs, which may have 150 to 200 megabytes of your right, because they are 15:40.960 --> 15:47.120 doing a source S Bombs. Most people are looking for other kinds of S Bombs, which are not yet produced by 15:47.200 --> 15:54.800 Yokto, several teams are working on this, including people at Cements. It may still take some time. 15:54.800 --> 16:01.600 So still that. Repeating the question, Yokto is creating a source S Bombs. There's 16:01.600 --> 16:09.120 work in progress at places like Cements in order to improve the scope of S Bombs that can be 16:09.120 --> 16:14.320 created out of tools like Yokto. Yeah, next thing. It looks fine. 16:14.320 --> 16:18.480 So you mentioned, for example, Alpine Linux. I'm also not aware of Yokto, because we 16:18.480 --> 16:24.240 would ask S Bombs for Alpine Linux. But what we did, we just told you to look, this is the 16:24.240 --> 16:29.200 own screen, but there's a little plot. And this is the description, how to get out of the blue plot 16:29.200 --> 16:34.480 in S Bombs. That's easier than spending weeks or months and finding the tool that may be 16:34.480 --> 16:39.280 due to the pattern. So it depends a little bit of what kind of S Bombs you're looking for. 16:39.280 --> 16:46.640 So if you understand you say you may, probably it's less time to do it manually than spend 16:46.640 --> 16:54.480 the time. So comment was, if you understand you say you might take less time to just 16:54.480 --> 16:58.080 manually put together an S Bombs and then getting the tool straight down. There's a question 16:58.160 --> 17:02.080 at the back first and then we had a time. All right. Thank you very much. 17:02.080 --> 17:04.080 Find me around.