Hi everybody, so I'd slid it over. Welcome to Struggles with Making Esperance for
Sea Applications. So if I use a modern language and I'm illustrating here with Dart, then
things are easy. I can just take a lock file that I've used against my package manager and
throw it into a tool like sift or trippy, and it's going to generate an s-bomb for
me. Are you okay?
So just about any modern language using a package manager is going to generate a lock file
and I can take that lock file and put it into one of those tools and I've got a generated
s-bomb. That might just be a starting point for an actual good quality s-bomb, but it's
a good starting point. Now the problem with sea is I don't get a lock file and it's
a huge problem because sea is a mountain of code out there. So penis 2 all did an excellent
presentation at EMF camp last year. You can find that presentation on the CCC website.
He was talking about Cherry and Morello and the problem with legacy code bases and the fact
that so much of it is unsafe languages. And so there you are. As of today, just about
six and a half billion lines of open source sea, two and a quarter billion lines of sea
plus plus. And if we compare that to rust, rust is only 57 million lines. So some of you
would have seen Daniel Stenberg talking yesterday about when's curl going to be rewritten
in rust and his answer is never. So hi, I'm Chris. I'm an engineer at a company called
that sign. We build a platform for inter-end encryption and some zero trust net working tools
on top of that platform. Our customers care about security. So how do we show them
that we care about security? Well, I talk about a trifecta of security visualization.
So we adopted open SSF scorecards first. Then we started producing S-bombs and doing salsa
for our builds. And so everything that we're doing, we try and have that trifecta of
scorecard, salsa, and S-bombs. Last year, one of our customers said, we love what you're
doing, but we'd like your thing to run on an open WRT router with a MIPS chip set and just put
it into two megs of flash. That's our limit. And so that was not going to support the
dart demon that we build at the moment. And I looked at rust and rust wasn't actually going
to give me a binary that was small enough. And so we've had to rewrite it in C. As we've
been building this C stuff, I want to produce S-bombs. And so this is a journey through
how I fail to actually produce S-bombs for our C binary. So I'm going to talk about things
I've tried and found wanting. I'm going to talk about some things that I've come across
that show promise of a way ahead for C-based ecosystems. I think in the long run, the
Linux distributions are going to kind of solve the peredow 80% of this problem for us. And I
also think C-make should probably be the focus of our efforts for resolving that residue.
And then there's going to be a lot of long-tale to worry about in that. What was it eight
three quarter billion lines of legacy code that's out there? So how not to make an S-bombs
for a C project? The first thing I found out there was a thing called C-make S-bombs. And since
I was using C-make to build the binary, this looked like it would be very promising. C-make
S-bombs will help me with my NTIA boilerplate. So I can say who I am and what it is. And it
doesn't do anything at all to address dependencies. My dependencies are pretty simple. So I use
embed TLS, C-Json and UUID. So I could probably do this manually and I guess some people might
even be trying to do that. But I'd really like something that's using my C-make declarations
of my dependencies and generating based upon that. It's also S-pdx only for those who care
about being bilingual in their S-bombs. At this point I had a chat with Ryan where and Ryan
somebody who's very involved in OpenSSF stuff will be familiar to a bunch of people in this room.
I'd been talking to Ryan about scorecardy things. I said, hey Ryan, like what are you doing at Intel
to generate S-bombs for C? And he was like, oh, I'm glad you asked. We're doing a ton of stuff,
but none of it's really kind of baked yet. Have you considered Conan? I had not. I'd never
even heard of Conan. So I went and looked at Conan. And so Conan is a package manager for C and C++.
So it should solve this problem of giving me a lock file. And it also has many of the popular
dependencies already packaged. So my lead developer on the C rights for the demon was like, yeah,
I took a look at Conan. It seems to have all of the things that we use there already. Maybe we should adopt this.
I then created some trivial applications to test Conan.lock and through that into sift and got
absolute garbage at the other side of it. And so the CFEs describing them as incomplete is probably
saying more than with actually there. The other challenge I found with Conan is it's got excellent
documentation for version one. And everybody's moved over to version two. And so I'm imagining
those people were kind of involved in writing version two because there's no documentation there for
newer doctors like me. So it's kind of hard to get into in a little bit frustrating at the moment.
I think I'd like to like Conan, but it hasn't made made it easy for me to get into. And also,
the tools aren't generating good espons from those lock files yet. So the next thing on my journey
was an Intel tool, CV Bintool. And this scan's binaries. So I don't need to integrate it into my
tool chain. I can just build my binary through it at CV Bintool and it'll tell me what's inside.
Yeah, right. So CV Bintool has limited dependency recognition. So my trivial demo app that I was doing,
it would find Z-lib in that. And it also gives me a false positive on that Z-lib because the Z-lib
was actually a patched one from an Ubuntu distribution. But it was telling me about all of the CVEs
associated with the un-patched version of that Z-lib. So not very confident in spiring.
I do a podcast with a guy called Nick Selby and he used to work for trailer bits.
I bet there's somebody from trailer bits in here in the room as well. And they have a tool called
It Depends. And I'd heard Nick talking about this and actually we've heard this word.
These words so many times today already. It depends. Well, there's a tool called it depends.
And it claims to support CMake projects. And it also now has Cyclone DX support in the December
24 release after three years of laying follow. And I threw it at my CMake project and I got nothing.
And it just doesn't empty return. There's been an open GitHub issue about that since February
22. And the project appeared to be abandoned when I was doing this in the middle of last year.
And there seems to have been a flurry of activity in December. So I'm getting somebody's thrown
a bunch of money at trailer bits. I'm loving it here. What's been going on there?
I don't have an inside track on trailer bits anymore. So I don't know what's going on.
But they're coin-operated, I guess. And the contract had run out. And then it seems somebody's
found an interest in it again. And activity is happening. So some rays of hope.
Victor, selling the second row there does sort of co-chairing of one of the Caesar
working groups. He got together a group of people recently to talk about this challenge of
C. S. Bombs. And somebody from the yokto project came along and talked about what they're doing.
So yokto is a meta-distribution. It is a thing that lets you create your own Linux distributions.
Very popular in the embedded world, especially things like automotive. We do actually have some
of our customers asking for yokto stuff. So I've been poking my head into it a little bit.
And yokto, because it is essentially a distribution and package manager, knows everything about
what you've got there and can generate an S. Bombs in SPDX format, which is kind of nice and cool.
There is some concern there that the generated SPDX can actually be bigger than the image
that you're going to put onto your device. But it kind of illustrates that if you're a distribution
with a package manager, then you've got all of the metadata that you need. And their story
was basically they wrote a Python script to mangled the metadata and then now able to spit out
SPDX, which is nice. And similarly Zephyr, so we heard about the equivalent Apache project
a little earlier. Zephyr is another way of building things for small embedded systems. And again,
they've got that similar view of end-to-end what's being built. And so that gives them all of the
appropriate metadata that can be reformatted into an S. Bombs. So what's going to happen next then?
Well, I'm actually really surprised that Vedha in particular is not shipping S. Bombs for
Rell, because I'd have thought in response to the executive order, there would have been.
They are. Since when?
Okay. So.
Yeah, but it's more than a year.
Yeah, there are many things.
There's been a while, yeah. Sorry, go ahead.
So I'm expecting the mainstream Linux distributions to start shipping S. Bombs. It sounds like the
secret Rell ones, if you press the right contract buttons, I'm guessing. But we want Linux to be open.
And so I'm hopeful that the mainstream distributions are on the cusp of using their package
managers and the metadata that they already have to start generating S. Bombs and giving them to us,
so that we can make use of that. And I think for a lot of that, see package surface area,
it's going to be used in the context of a Linux distribution and the packages that we're installing
from that. And so it's going to solve probably about 80% of the problem.
So what about the other 20%. Well, I think of the other 20%
and see make has pretty much taken over the build processes of modern C applications.
And see make gives us a way to express dependencies.
And so if it gives us a way to express dependencies, it should also be relatively straightforward
to give us a way to express those dependencies into an S. Bombs artifact.
The problem that we get here is, I came across a brilliant article recently, which was talking
about what it called the make file problem as a different way of describing cargo culting.
And who in this room considers themselves as C make expert?
That's more hands than I expected to see. Absolutely wonderful. And that's we've got a room of
top class experts at Phos Deb. Just about all the times when I'm talking to people in tech,
and I say, do you consider yourself a C make expert? They're like, no, not me.
Because most of the C make that's out there is kind of copy-pastored from other C make.
And hardly anybody actually understands what's going on with it. And it's challenging. And so
I feel like the expertise to create S Bombs from C make isn't yet kind of focused enough on the problem.
So in review then, I kicked the tires on a whole bunch of tools and they didn't make me happy.
There's chances of improving all of these things.
This is a lot easier if you've got a package manager. And so in the case of things like
Yokto and Zepha, they are essentially package managers. And so they can actually generate S Bombs for us.
I think mainstream Linux distros are going to solve the 80% of the problem.
And I think C make should probably be our focus as a community for the rest of the residue of that
problem or it's the first priority of that residue. There will of course be lots of
long-tailed worry about all of the, you know, or how stuff that's out there, for instance that's
not even using C make. And, you know, it's going to be an iterative process and I think it's going
to take time. A couple of resource links, Victor, you know, got me to do a guest post on his
S Bomify blog, a little while back, which is sort of the blog version of the talk that you've just heard.
And the Yokto documentation is excellent. So there's a whole section now in their documentation
about Yokto, about S Bombs from Yokto. Thank you very much for your time. You can email me
at atsign.com or find me on socials at CPS1. And I've got a few minutes for questions I have.
Yeah, really, really, really good presentation. I'm 13 to say. But about Yokto, so
Yokto produces an S Bombs, which may have 150 to 200 megabytes of your right, because they are
doing a source S Bombs. Most people are looking for other kinds of S Bombs, which are not yet produced by
Yokto, several teams are working on this, including people at Cements. It may still take some time.
So still that. Repeating the question, Yokto is creating a source S Bombs. There's
work in progress at places like Cements in order to improve the scope of S Bombs that can be
created out of tools like Yokto. Yeah, next thing. It looks fine.
So you mentioned, for example, Alpine Linux. I'm also not aware of Yokto, because we
would ask S Bombs for Alpine Linux. But what we did, we just told you to look, this is the
own screen, but there's a little plot. And this is the description, how to get out of the blue plot
in S Bombs. That's easier than spending weeks or months and finding the tool that may be
due to the pattern. So it depends a little bit of what kind of S Bombs you're looking for.
So if you understand you say you may, probably it's less time to do it manually than spend
the time. So comment was, if you understand you say you might take less time to just
manually put together an S Bombs and then getting the tool straight down. There's a question
at the back first and then we had a time. All right. Thank you very much.
Find me around.