Okay everyone, hello and welcome we're starting the next session with the first talk which
is going to be a long talk and this is by Tristan the computer guy Ross and he's going
to talk about describing Nick's closures using S-bombs.
All right, so round of applause for Tristan please, a warm welcome here at Boston.
I think you came from far away, right?
All right, so go ahead.
Hi, I'm Tristan Ross and I've been working at the German systems and one of the things
that I work with a lot is S-bombs, which are softer build materials and so I am sure not
many of you know what S-bombs are, so what are S-bombs, effectively they are a collection
of software with metadata, usually an editor says what version the software is and name any sort
of identifiers, so you have a few different ways of identifying the packages, usually contains
the patches and possibly some other metadata.
The convenient thing about this is that you now can easily express in an industry standard
way what a package closer looks like, which aside from Nick's is actually very useful because
these are actually just pretty easy to work with and so why do they matter?
Well, for once provenance it's very easily able to guarantee what software you have to
want in one system, another one is vulnerability tracking so that you can take in S-bombs
and put it into some tool like N-core's bribe, which then will give you all the vulnerabilities
associated with in that closure, it can also do the penalty tracking because the S-bombs
contains references to each dependency, you are able to then effectively graph the dependencies,
just to do auditing with S-bombs, so since you know what licenses, the sources and all
that are associated with a package, you can easily audit it and this is without evaluation
since it's all generated and the fun thing about this is S-bombs actually look like Nick's
loaders, so if you just express every package as being a single derivation in S-bombs you
effectively have a knit store closure inside of something like an S-p-x S-bombs or a cyclone
DX X-bombs and how do you make S-bombs? So there's a few tools out there, one is S-bombs
X, which is random Python, it works pretty well, a lot of people use it, it's mostly
eval-based, uses like it leaves nix and with the meta command, you also have the bondbombs
which it's able to use effectively something you add in to next as a flake or something
else and you just give it a set of packages and it evaluates it and gives you a S-bombs as you build
it. You also have SIFT which is a lot more primitive compared to the others, it just looks
that whatever paths are reverence and will give you an S-bombs and then at the current systems
we wrote a new tool called flakebombs which is written in Rust, it is able to do parallel
evaluation and it outputs a cyclone DX format and it also is able to give you the provenance
information for every single package inside of a closure so deformation would be like what nix
cache it came from and so you're able to guarantee and at a state what your package set looks
like. So what else can S-bombs do? So for one you can replicate between systems and it's actually
very easy to do with just using the next store command and just be able to dash or on it to
realize everything you can do a vulnerability tracking and audit software sources also provides
an easy way to do introspection since you have an easily portable way of being able to express it
and then since S-bombs always have a minimal set of attributes that you can specify
there is an ideal way these S-bombs can look like and ideally you do not want less metadata
you actually want more metadata and so that would be being able to track everything and anything
inside of a package set so that is you want to know what all the patches are doing
where they come from you want to know all the vendor dependencies of a package like let's say you
have something that is written in rust and you're pulling cargo you can't easily introspect that
and so being able to have a way to specify that is helpful and then you also want to be
to track variance so like if you have certain packages that are the same as that package but with
a feature turned off like let's say some package has a TPM support and that's not always enabled
being able to know that is very useful so this is that's why I generated both part of it
for L of M as you can see it pulls out all the information you have all your licenses you have
a common package enumeration you have references and some properties with nicks floor pots referenced
but this is not enough we're missing quite a bit from the packages so for once vendor dependencies
is a big one the package type which effectively is saying what kind of package so if we look back
on the previous slide you can see L of M is marked as a library but not everything is a library
you often have things like Google Chrome or your applications so being able to mark
what kind of software you have in your closure is very useful because you can also mark what is
not software because there's a problem with the S-bombs that if you build an S-bombs for a
knit store closure source paths are referenced because they are in the tree and so being
able to mark them as not being natural software and being the sources would help prevent false
positives since not every package always has the right metadata for source code and then you also
want to have patch information so you want to know like what CVEs or a commit that a patches
associated with or a pull request associated with so it's very easy to backtrace where that patch
comes from in a machine readable way and you also want to be able to get the not just the paths
that are packaged or declared in the build inputs and various attributes but also what are string
interpolated which is difficult because that unremove a lot of the metadata that you get and
so being able to unwrap that easily up to a lot so there's a few PRs that exist to be able to
add some of those missing features one of them is by Hans Doshim in adds package URLs this is a
very common way of being able to describe a package in a URI format and it's effectively just you have
package colon and then what kind of packaging solution slash the name and then you're going to have some
stuff out of the question mark to be able to declare any information like the next door path that comes from and then I've been
working on the package types so this is a way of being able to describe what kind of software this
that you're packaging and then there is also from Josh Hoffer serializing metadata the metadata attributes
into the next door by putting it into JSON and so that helps with the string interpolation
and that's kind of it any questions?
so thank you very much I wasn't expecting the talk to be over quite yet so we actually do have time for
questions right away now are there any questions okay there's somebody I'm going to bring you back
so this is essentially this so we are what you're working on is describing not like the
closure like how the closure gets made but what actually is in the closure to make it easier to get
generate good response from next derivations if I understood it correctly I'm sorry couldn't quite catch that
so if I understood it correctly what you're working on is not like describing how the closure gets built
but like turning a mixed derivation into an espa. Yes so effectively I'm trying to be able to
not really get the recipe of a derivation but rather the information around a desired derivation
so that's purely the metadata rather than how I package this built however as well since we do
reference the store paths we can then look those store paths back up get the derivation and then
complete the rest of the story for that piece of path software I see thank you
any other questions no well great so thank you very much Tristen thank you for staying on time
they can finish even ahead of time that was really good for us schedule so that's great and
yeah we're going to continue with two shorter talks now