WEBVTT 00:00.000 --> 00:14.580 Okay everyone, hello and welcome we're starting the next session with the first talk which 00:14.580 --> 00:22.920 is going to be a long talk and this is by Tristan the computer guy Ross and he's going 00:22.920 --> 00:27.400 to talk about describing Nick's closures using S-bombs. 00:27.400 --> 00:32.840 All right, so round of applause for Tristan please, a warm welcome here at Boston. 00:32.840 --> 00:37.600 I think you came from far away, right? 00:37.600 --> 00:41.720 All right, so go ahead. 00:41.720 --> 00:47.480 Hi, I'm Tristan Ross and I've been working at the German systems and one of the things 00:47.480 --> 00:55.800 that I work with a lot is S-bombs, which are softer build materials and so I am sure not 00:55.800 --> 01:03.560 many of you know what S-bombs are, so what are S-bombs, effectively they are a collection 01:03.560 --> 01:13.080 of software with metadata, usually an editor says what version the software is and name any sort 01:13.080 --> 01:18.360 of identifiers, so you have a few different ways of identifying the packages, usually contains 01:18.360 --> 01:22.680 the patches and possibly some other metadata. 01:22.680 --> 01:29.960 The convenient thing about this is that you now can easily express in an industry standard 01:29.960 --> 01:38.480 way what a package closer looks like, which aside from Nick's is actually very useful because 01:38.480 --> 01:45.400 these are actually just pretty easy to work with and so why do they matter? 01:45.400 --> 01:51.200 Well, for once provenance it's very easily able to guarantee what software you have to 01:51.200 --> 01:58.080 want in one system, another one is vulnerability tracking so that you can take in S-bombs 01:58.080 --> 02:05.240 and put it into some tool like N-core's bribe, which then will give you all the vulnerabilities 02:05.240 --> 02:11.160 associated with in that closure, it can also do the penalty tracking because the S-bombs 02:11.160 --> 02:18.280 contains references to each dependency, you are able to then effectively graph the dependencies, 02:19.040 --> 02:25.720 just to do auditing with S-bombs, so since you know what licenses, the sources and all 02:25.720 --> 02:33.000 that are associated with a package, you can easily audit it and this is without evaluation 02:33.000 --> 02:39.880 since it's all generated and the fun thing about this is S-bombs actually look like Nick's 02:39.960 --> 02:48.760 loaders, so if you just express every package as being a single derivation in S-bombs you 02:48.760 --> 02:58.200 effectively have a knit store closure inside of something like an S-p-x S-bombs or a cyclone 02:58.200 --> 03:07.200 DX X-bombs and how do you make S-bombs? So there's a few tools out there, one is S-bombs 03:07.280 --> 03:14.800 X, which is random Python, it works pretty well, a lot of people use it, it's mostly 03:14.800 --> 03:23.560 eval-based, uses like it leaves nix and with the meta command, you also have the bondbombs 03:23.560 --> 03:36.400 which it's able to use effectively something you add in to next as a flake or something 03:36.400 --> 03:45.040 else and you just give it a set of packages and it evaluates it and gives you a S-bombs as you build 03:45.040 --> 03:52.240 it. You also have SIFT which is a lot more primitive compared to the others, it just looks 03:52.240 --> 04:00.560 that whatever paths are reverence and will give you an S-bombs and then at the current systems 04:00.640 --> 04:06.880 we wrote a new tool called flakebombs which is written in Rust, it is able to do parallel 04:06.880 --> 04:15.600 evaluation and it outputs a cyclone DX format and it also is able to give you the provenance 04:15.600 --> 04:23.440 information for every single package inside of a closure so deformation would be like what nix 04:23.440 --> 04:31.680 cache it came from and so you're able to guarantee and at a state what your package set looks 04:31.680 --> 04:38.480 like. So what else can S-bombs do? So for one you can replicate between systems and it's actually 04:38.480 --> 04:45.920 very easy to do with just using the next store command and just be able to dash or on it to 04:45.920 --> 04:55.520 realize everything you can do a vulnerability tracking and audit software sources also provides 04:55.520 --> 05:02.240 an easy way to do introspection since you have an easily portable way of being able to express it 05:05.760 --> 05:13.440 and then since S-bombs always have a minimal set of attributes that you can specify 05:14.400 --> 05:20.800 there is an ideal way these S-bombs can look like and ideally you do not want less metadata 05:20.800 --> 05:29.040 you actually want more metadata and so that would be being able to track everything and anything 05:29.040 --> 05:34.240 inside of a package set so that is you want to know what all the patches are doing 05:35.280 --> 05:41.040 where they come from you want to know all the vendor dependencies of a package like let's say you 05:41.040 --> 05:47.840 have something that is written in rust and you're pulling cargo you can't easily introspect that 05:47.840 --> 05:55.440 and so being able to have a way to specify that is helpful and then you also want to be 05:55.440 --> 06:02.160 to track variance so like if you have certain packages that are the same as that package but with 06:02.160 --> 06:08.160 a feature turned off like let's say some package has a TPM support and that's not always enabled 06:08.320 --> 06:17.520 being able to know that is very useful so this is that's why I generated both part of it 06:17.520 --> 06:23.840 for L of M as you can see it pulls out all the information you have all your licenses you have 06:23.840 --> 06:30.720 a common package enumeration you have references and some properties with nicks floor pots referenced 06:31.680 --> 06:40.800 but this is not enough we're missing quite a bit from the packages so for once vendor dependencies 06:40.800 --> 06:46.720 is a big one the package type which effectively is saying what kind of package so if we look back 06:46.720 --> 06:53.600 on the previous slide you can see L of M is marked as a library but not everything is a library 06:54.320 --> 06:59.840 you often have things like Google Chrome or your applications so being able to mark 07:00.720 --> 07:06.480 what kind of software you have in your closure is very useful because you can also mark what is 07:06.480 --> 07:14.240 not software because there's a problem with the S-bombs that if you build an S-bombs for a 07:14.240 --> 07:24.000 knit store closure source paths are referenced because they are in the tree and so being 07:24.000 --> 07:30.240 able to mark them as not being natural software and being the sources would help prevent false 07:30.240 --> 07:39.520 positives since not every package always has the right metadata for source code and then you also 07:39.520 --> 07:48.480 want to have patch information so you want to know like what CVEs or a commit that a patches 07:48.480 --> 07:53.760 associated with or a pull request associated with so it's very easy to backtrace where that patch 07:53.760 --> 08:05.120 comes from in a machine readable way and you also want to be able to get the not just the paths 08:05.120 --> 08:12.160 that are packaged or declared in the build inputs and various attributes but also what are string 08:12.160 --> 08:20.080 interpolated which is difficult because that unremove a lot of the metadata that you get and 08:20.080 --> 08:27.680 so being able to unwrap that easily up to a lot so there's a few PRs that exist to be able to 08:28.320 --> 08:38.240 add some of those missing features one of them is by Hans Doshim in adds package URLs this is a 08:39.440 --> 08:47.600 very common way of being able to describe a package in a URI format and it's effectively just you have 08:48.560 --> 08:57.280 package colon and then what kind of packaging solution slash the name and then you're going to have some 09:00.240 --> 09:06.880 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 09:06.880 --> 09:15.600 working on the package types so this is a way of being able to describe what kind of software this 09:15.680 --> 09:25.600 that you're packaging and then there is also from Josh Hoffer serializing metadata the metadata attributes 09:25.600 --> 09:33.040 into the next door by putting it into JSON and so that helps with the string interpolation 09:34.560 --> 09:37.840 and that's kind of it any questions? 09:46.240 --> 10:00.240 so thank you very much I wasn't expecting the talk to be over quite yet so we actually do have time for 10:00.240 --> 10:07.120 questions right away now are there any questions okay there's somebody I'm going to bring you back 10:16.480 --> 10:23.040 so this is essentially this so we are what you're working on is describing not like the 10:23.040 --> 10:28.720 closure like how the closure gets made but what actually is in the closure to make it easier to get 10:28.720 --> 10:36.000 generate good response from next derivations if I understood it correctly I'm sorry couldn't quite catch that 10:37.200 --> 10:42.800 so if I understood it correctly what you're working on is not like describing how the closure gets built 10:42.800 --> 10:50.400 but like turning a mixed derivation into an espa. Yes so effectively I'm trying to be able to 10:51.280 --> 10:58.800 not really get the recipe of a derivation but rather the information around a desired derivation 10:58.800 --> 11:06.160 so that's purely the metadata rather than how I package this built however as well since we do 11:06.160 --> 11:11.360 reference the store paths we can then look those store paths back up get the derivation and then 11:11.360 --> 11:16.720 complete the rest of the story for that piece of path software I see thank you 11:41.440 --> 11:51.280 any other questions no well great so thank you very much Tristen thank you for staying on time 11:51.280 --> 11:58.080 they can finish even ahead of time that was really good for us schedule so that's great and 11:59.280 --> 12:06.320 yeah we're going to continue with two shorter talks now