Next up, more traditional technologies.
See you in the simplest class of both of us, we've come by our admin.
Alright, so, as you all are aware, modern software is written in rust or whatever, but
there's a lot of C still, and we've been talking about C projects all day, and one of the
things that I keep hearing is, hey it would be nice if we had S-bomb data for C, so here we go.
For those who don't know, I do not come from a computer science background.
I got into open source, free software as kind of a hobby, turned into a career because
I realized you can make a lot more money as a software engineer than doing any sort
of empirical research, so that's fun if you want to talk to me about either software engineering
or psychology, I'm always down.
I've been working on Alpine since 2009, before that I worked on WN.
I've done all sorts of stuff in Alpine, the X64 port, I've done a lot of Loonarch porting
mostly because I found that fascinating.
I maintain the G and U tool chain in Alpine, so GCC, B and U tools, all of that.
The networking stack, I have up done in G, a lot of core U-tillies, Libu context, G-libc,
compatibility, et cetera.
I also started Alpine's security team in 2021.
I needed a actual, like, cert-type team to help all of the people using Alpine in the world.
We had, like, security data, but it wasn't very good, so I built out a security team
as part of my work with the Google Open Source security team.
My focus, largely, is on ensuring Alpine sticks around for the foreseeable future.
There's a lot of conversations about that every year, because Linux distributions are hard.
But mostly, I'm obsessed with how software is actually composed, how software gets stacked
into different configurations and all of that, because it basically takes the billage to
build all of this.
Basically, it's that story that I've been trying to track for so long.
So I'm on Macedon, and sometimes I'm blue sky, I also have a LinkedIn, but I hate LinkedIn.
I hate everything LinkedIn represents, so I'm not linking it here.
Why am I here?
So last year at Boston, there was a talk about somebody who told us a story about how
he struggled to build C and S-bomb spruce, C-make project, and how he had to port his entire
project over to C-make, and he was not very happy with how things were going.
So I've been working on this C-S-bomb problem, literally since 2021.
It has been a long time to get to the point where we're at.
This is largely because C and the model that S-bombs are built around, it's not really 100%
shaped the way it is.
So this talk is for you, Chris, I hope you enjoy it.
Now that it's probably not very useful to you.
So I could have seen C and C++ projects kind of predate the current model for how dependencies
get distributed.
Like if you go, you have go packages with rust, you have prates, and Java, you have
Maven, JavaScript's closer, but Java has Maven so that doesn't, you know, that's more
into modern direction.
So with those tools, you just pick an S-bomb generator of your choice, point it out a
lot, file, hit the button, you get a build time S-bomb.
C and C++ have modules now, nobody cares about them.
Well, some people care about them, but in the real, in the wild, they haven't been adopted
yet, very widely.
Libraries, traditional libraries, and SDKs maintain their dominance over modules.
So there's no packages, no lock files, and dependency management, therefore exists elsewhere.
Hello, I manage your dependencies.
Well, I don't, but my code does.
So this is package comp, I read, there's two SDK managers really for C and C++.
There's C-make, which I'm sure all of you are familiar with, and many of you have probably
cried or sworn at it, especially when it, you know, gives you confounding error messages
and all of that.
But some people seem to like C-make.
It started its life as a project at the Department of Energy, so, you know, if it feels
like you're dealing with the government when you're working with C-make, it's because
you are.
On the foot side, the known people made package config back in 1999.
You might remember a long time ago, like, building software running config, you know, running
to configure script, and then it would be like, you need to go download package config.
That was a long time ago, now days, you get a package config implementation as part of
your distribution provided tool chain.
So what does package config do, and why do we care about it?
Traditionally, when you use package config, you get a date, okay.
So package config is a client in a way that accesses and manipulates a database about
software dependencies, specifically SDKs.
You query it as a form of constraints.
The constraints must be satisfied.
The constraints are also graphs that you then walk over.
The original package config didn't strictly work that way.
It was more of a brute force search.
I hope everything works out.
I hope you have all of your dependencies if not fail.
Package config actually has a proper solver.
That's the main difference.
Typically every unix build system uses package config in some way.
Automate has integration through the binnerable package.informacroset, which I'm now
stuck maintaining, even though I don't know anything about maintaining informacroses.
There's also a C-mate, which has a package config macro, and a mess in which it's kind
of, or mason, I don't know how to pronounce it.
That's the new kind of hotness in terms of replacing like automate.
Basically they look at C-mate and wait, hey, there's a lot of cool ideas here, but C-mate
is unpleasant to use, so we're going to make our own.
So they did.
So with package config, you ask it for certain data, and then it calculates a solution based
on your query and it gives you back compiler flags.
That's the traditional use.
There are also other functions that have been added since then, such as key value storage
and a whole bunch of other things, although it's baked onto this one binary package
config, it's a horrid interface, but we're kind of stuck with it.
So package comp however has additional tools, which are useful for S-bombs.
We have two different S-bombs, generators in fact.
There is BOM tool, that's the one that I wrote in 2022, and it generates an S-PDX 2.3 S-bombs.
In package config get today, we also have an S-PDX 3 generator, which is presently a work
in progress, well, technically it's an S-PDX 3.0 light generator.
But you get the JSON out the S-bombs, and you can do cool JSON out the stuff with them.
The other main thing that you get is the package comp, directed graph output tool, which
you can fit, which you can fit into graph is dot utility, and that allows you to visualize
your actual dependency set, which is very useful.
So how does this apply to an actual application, like, say you want to build a C program,
or a C++ program, like some sort of calendar app, or whatever, with GTK, or something
with QT.
How do you do it?
So the easiest way is you ask your build system, like me-son, I'm just going to call it me-son,
because that's what I normally call it.
Yes, me-son, to build you a PC file that describes your project.
That's very similar to what would be considered a lock file, and another language ecosystem,
because you have your directed set of constraints, and then you can use that data to build
an S-bombs.
Once you have your PC file for your app, and you don't have to install it, we have this
whole concept called uninstalled PC files, it's a whole thing.
If you want to know about it, it's incredibly cursed, just catch me in the hallway.
But you take this PC file, and you analyze it with one of the aforementioned tools, and then
you get an S-bom, or graph is document or whatever.
So now it's demo time.
If you saw I had a console window that I dragged over, and so we're going to take a look at
what we can do, and then we're going to talk about the next steps.
So let's see if I can do that real quick.
So far, the demo gods seem to be cooperating, but you never know, oh, no.
So we're going to do a build real quick.
I don't remember if I cleaned it first, so I'm going to just do that real quick.
So we're building a very simple application here.
This is just a hello world application to show you that this is in fact a real application.
I will run it.
It went to the wrong screen.
But no, there it is.
Anyway, this is just a GTK for application.
But if you notice, we have an SPDX2 S-bom, and an SPDX3 S-bom, and then we also have our dependency
graph, which I do some editing said to make it more friendly to show on a big screen.
So if we, I actually have that dependency graph, I actually opened this, so if I can move
it over here, you can't, there.
You know, I used to say, I used to tell people use KDE when you're presenting, but
there's my mouse.
Okay, so up here, we have the hello world app, and we directly pull in GTK, which depends
on Pango, which is the known text library.
Technically that's Pango Cairo, which depends on Pango, which depends on Harfbuzz, which
depends on GDPXBuff, blah, blah, blah, blah.
So we can scroll through and visualize this whole thing, and that's a lot of dependencies,
right, for a simple hello world desktop app.
In fact, we have Vulcan in here, which means that we're doing stuff with GPUs, just a render
hello world, basically.
So we keep going, it depends on G-lip, because everything, in the known world, depends
on G-lip, so as you can see, there's tons and tons and tons and tons and tons and tons
and tons of paths pointing to G-lip.
And then we have U-tilinic stuff over here, and more U-tilinic stuff over here, and
we have Z-lip, and anyway, so the interesting thing is package comp actually can figure
out what is a direct dependency versus an indirect dependency.
And that's very important when it comes to vulnerability management, because as other
people alluded in earlier presentations, like the Zephyr person, for example, you can have
a CVE in a package, and maybe that's a problem, maybe it's not a problem, you know, people
struggle to reason about that, which is why there's apparently an entire industry now selling
zero CVE images in various forms.
I think all of those products missed a point, though, because what really matters is, is
that vulnerability reachable or not.
So my GTK for hello world app that I demonstrated a moment ago, which was not vib coded.
I just googled it and typed it out.
That application has an indirect dependency on Z-lip, but it's an indirect dependency.
So there's a CVE in Z-lip, it probably doesn't actually matter in practice, because there's
no rectipinancy.
So we're running short on time, so I'm going to go back to the slides, because I have
a couple more slides, just a few more, and, oh God damn it, all right, so let's talk
about what we need to do, but actually hold on.
Just to show that these as bombs are real, I'm going to show that they're real.
Somehow, there, okay, so we can use the Kubernetes, do document outline on the hello
bus, then voila, CES bomb, okay, so now we will go back to the slides, which it, yeah,
thank you computers, I hate them.
So there's a few things we need to do, quality of life improvements are important.
Right now, with Nissan and Automate, you have to stitch everything together yourself to
get these SPDX S-bombs as build output, and we need more data in the package-config files,
and that will yield higher quality S-bombs.
You have your SPDX S-bombs quality score tool, and right now we have a valid S-bombs, but
it would score like, you know, 4.0 or something, we want to score, you know, 8, 9, 10 on
it.
So we need more data in the PC files to do that, also because, at least in my experience,
there's some sort of ongoing, holy war about S-bomb formats, we probably want to have
a cyclone DX format building tool thing, and we need also to support package URLs.
So, you know, like I was saying, build system integration, the best way to get more S-bombs
is that you don't have to think about S-bombs, and like I was saying, that requires
Nissan and Automate to support it, see make already has a solution here, that was demonstrated
during the S-bombs.
This is kind of my thinking about how we can make Automate do S-bombs really easily, you
can just ask it to generate an S-bombs based on a PC file.
I have a patch that I'm about to submit to GNU to get that done.
Obviously, you still have to compose the PC file and all of that.
With Nissan, it's going to be a little bit more slick because Nissan already knows everything
that it needs to know in order to build an S-bomb out anyway.
So, essentially there what we're going to do is re-work the package config module to return
a specific package config object that represents the package config resource, and then you
can do stuff with it so you have your PC file that you generated, it's a package.generate
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
interim output and then render an S-PDX or whatever from it.
And it will use the right tool under the hood to get it done.
So we 놓 the logo, so we're talking in IRC about that, and of course anybody interested
can find me while we're still doing this Fosstum Thing.
Let's talk about S-b-DX metadata.
farters for additional fields, although after watching all of y'all, it's wonderful
talks. I've thought of about 10 more that I need to add.
What?
If there's three fields that you need that are missing, let us know first.
Well, fields I need to add to PC files.
So anyway, these are the four that are like super critical because if you can, if we can
add these to everything, the S-bombs that we generate with the S-bomq, and as soon as we
can get these changes into M-s on and all of that, I think we'll be in really good shape.
Please use these fields to improve your S-bomq minutes left. Package URLs are really fun when
it comes to package config because we're not describing a package, but we're also kind of
describing a package because it's in the name, right? Package config.
But the problem is, these are an intermediary package. It's an S-d-k. So we need to be able
to identify that this is the GTK4 SDK that came from Alpine or Debian or whatever.
So we need like a compound form of a package URL, basically, where we can be like this
is an SDK, and it came from here in this other package URL.
It's first, I have some thoughts, but we need that.
Cyclone DX, we need that because, again, we need that. People want it.
And thanks to everybody on that list because they've either given the package config
project money or they have paid me to work on this. Also, thanks to Tuka Passenen, I think
I got that right. He wrote the first version of SPDX tool, and we're presently in the
process of beating it into shape and getting it production ready.
And thanks to all of you for hopefully adding these PC fields and to all of your projects
in making SPDX and CNOT suck.