WEBVTT 00:00.280 --> 00:02.320 Music 00:04.620 --> 00:07.320 Piccadron is done, who's going to tell us 00:07.320 --> 00:09.120 everything about what we need to do 00:09.120 --> 00:10.600 to be the zenarch of the traditional 00:10.600 --> 00:11.840 Ashillis, that's up to it! 00:11.840 --> 00:12.880 There ya go! 00:12.880 --> 00:13.600 That's right. 00:13.600 --> 00:14.600 junto with Ashillis 00:15.100 --> 00:16.820 h 00:17.820 --> 00:20.080 Hi! 00:20.080 --> 00:21.160 Uh… hello? 00:21.160 --> 00:24.600 So, leave us into the video 00:24.600 --> 00:26.760 questions questions. 00:26.760 --> 00:28.080 We. 00:28.080 --> 00:29.120 Alright, inn 00:29.120 --> 00:37.520 not great. So then let's go to who wants their distribution or themselves to use all the 00:37.520 --> 00:41.520 stuff that Lena was talking about in a C-TM dog. All right, that looks pretty good. 00:41.520 --> 00:45.120 Who is actually using this stuff that Lena is talking about in a C-TM dog? 00:45.120 --> 00:59.360 No, not very great. So lots of you want to use it, not many are using it yet, but before 00:59.360 --> 01:06.080 you actually start using it, we need to talk. We need to have a chat. We need to talk about dog 01:06.080 --> 01:14.400 fooding. What is dog fooding? It's the act of using your own software. What is the state of 01:14.400 --> 01:21.040 dog fooding in system D then? It's a good question to ask, right? And so let me start with just a picture. 01:21.040 --> 01:26.960 Right from the secret internal system D maintain a chat. Like this comment that you're using 01:26.960 --> 01:34.400 Rm0 and not Sudo anymore. 18 fat only one of them actually liked it, which was mean. So we have 01:34.400 --> 01:40.720 this Rm0 thing to replace Sudo, but is any system D maintain actually using it? I don't know. 01:40.720 --> 01:51.120 There we go. Not yet. Of course, Rm0 is one tool. So it's not a proper measurement of 01:51.120 --> 01:58.560 whatever dog fooding correctly. So there's a list of Linux inventions. Right, there's unified 01:58.560 --> 02:04.320 kernel images, the old stuff, GPT Auto and then the new stuff, PCR log and all the other stuff, 02:04.400 --> 02:12.480 Linux has invented over the years. It's not all of them. And the list might have been chosen 02:12.480 --> 02:17.280 to make them look bad, but we'll see that in the next slide. So let's take a look like what is 02:17.280 --> 02:26.720 Linux actually using according to my guess. I think it looks like this. So Linux runs stock for 02:26.720 --> 02:33.280 door workstation installed last time I asked, which is sure Yavkrab setup because for 02:33.280 --> 02:38.880 door doesn't encrypted with this. He uses HomeD, he didn't know that. And he gets rid of Krab as 02:38.880 --> 02:44.240 well and replaces it with system D boot. So that are the good things, but then the other stuff 02:44.240 --> 02:53.680 is not really used at all. Yeah, to develop, but not to manage your system. 02:53.920 --> 02:59.760 Yeah, and then let's do it. Yeah, so 1.0 PCR like a unified kernel image, so I wasn't sure. Are 02:59.760 --> 03:05.840 you using unified kernel images? For the actual, yeah, for the list for door, it doesn't do it, right? So 03:05.840 --> 03:09.920 that goes rather PCR log, I guess, isn't used either. So that's for that as well. But 1.0 is green. 03:11.200 --> 03:16.000 So the overall conclusion is like, there's a lot more red than there is green, right? Which is 03:16.000 --> 03:21.200 not not great. Of course, we can just single a lot at Leonard. So I asked or I'm first 03:21.200 --> 03:27.920 or some other system D maintenance as well. Look, I'm using unified kernel images on a slaptop. 03:27.920 --> 03:32.720 I know that Zibigno is using make-or-side inner ID, so make-or-side becomes yellow because 03:32.720 --> 03:36.800 make-or-side inner ID is only a little bit of the all the stuff you can do with make-or-side. 03:37.360 --> 03:43.520 I know Mike is using system the GPT operator and credentials. So it's a little better, but still 03:44.400 --> 03:49.120 a lot of rats, right? Nobody's using gravity. Nobody's using signed PCR policies on a laptop. 03:50.000 --> 03:55.760 And the extension stuff isn't really being used either, because again, by would you, you have 03:55.760 --> 04:02.240 like a rideable user partition, so you just DNF upgrade to get your updates. There's no need for 04:02.240 --> 04:10.000 all the extension stuff. Why is this problem? So what happens is we merge a lot of new stuff with 04:10.000 --> 04:17.600 public APIs, but there's nothing immediately using that stuff. The public API then goes into 04:17.600 --> 04:23.600 this in a stable release. And we guarantee backwards compatibility, so once that happens, we can't 04:23.600 --> 04:30.160 change it anymore. We wait a little while. Someone tries to actually use the interface and it turns out 04:30.160 --> 04:36.320 it doesn't exactly do what's needed or needs changes or it's just incomplete. It's not often that 04:36.320 --> 04:42.400 like the interface is wrong. Most of the time it's just incomplete and there's like, you find out 04:43.040 --> 04:48.640 some important thing is missing for you to be able to use it effectively. And then we have to figure 04:48.640 --> 04:54.240 out how to either fix the interface or just complete it. This is pretty generic, like what 04:54.240 --> 04:59.040 it actually ends up looking like in practice, is that Lana, this is one merging all this public APIs. 04:59.600 --> 05:05.520 I'm the one trying to use them. I find out they don't work, and I have to complete them. Not 05:05.520 --> 05:12.480 amazing. So how do we make Lana talk with system D or in other words, how do we make Lana 05:12.480 --> 05:20.880 to his own consumer of his own stuff? It seems that the duration is fine. It seems that the situation 05:20.880 --> 05:27.520 is fine. Yeah, yeah, yeah. So all we need to do, of course, is create system D's own distribution 05:27.520 --> 05:32.400 rights. Like we reject the Unix philosophy, right? We've stolen DNS, we've stolen that work, 05:32.480 --> 05:35.920 we've stolen in it, we still have everything, so why not steal the distribution as well? 05:37.760 --> 05:39.760 That was a joke. 05:43.440 --> 05:48.080 Yeah, this slide is the one I expect to come on for our next. We'll see. 05:50.240 --> 05:54.880 We can't reinvent the entire real one we do this, right? It's just me. I don't have time to 05:54.880 --> 05:59.840 repackage the world. So we need to reinvent the real a little bit, but not completely otherwise 05:59.840 --> 06:05.520 that we'll never get done. It needs to be known because Lana is a known person. So if it doesn't 06:05.520 --> 06:10.800 have known, we'll never get Lana to use it. It has to use as many system D tools as possible, 06:10.800 --> 06:14.640 because if we're not using system D tools to build it, then we're not getting the dog feeding 06:14.640 --> 06:21.040 in the first place. The more system D tools we use, the more we exercise the interfaces and the 06:21.040 --> 06:26.480 implementation, the more bugs we find, which I hope we've fixed before it gets into the hands of 06:27.440 --> 06:33.280 users instead of after it gets into the hands of users. Using all the system D tools 06:34.320 --> 06:39.840 is in itself not enough, because if we package this with a system D, or if we use a system D 06:39.840 --> 06:43.840 stable release in this distribution, or at least in the version of it that Lana will run, 06:45.280 --> 06:49.120 it's too late, right? The public APIs we've been merged already, backwards combatability 06:49.120 --> 06:53.840 guarantee, and we can't fix them. So it has to run system D from straight from get main, 06:53.840 --> 06:57.920 so that we can immediately start using the new public APIs in the distribution, 06:59.120 --> 07:05.520 exercise them, make sure they work, fix them if they don't work before we're tied by backwards 07:05.520 --> 07:12.080 compatibility. And we have to enable easy acting on system D and the distribution itself, because 07:12.080 --> 07:17.760 we run Lana to run this, Lana needs to be able to behave on system D, so this needs to make that 07:17.760 --> 07:23.760 possible. We also run Lana ideally, not to just work on system D, but also implement all the 07:23.760 --> 07:28.560 stuff he adds to system D in the distribution, so that we have the end-to-end thing 07:29.520 --> 07:36.240 completed, and he gets to immediately consume the API C adds instead of waiting for any distribution 07:36.240 --> 07:42.000 to eventually hopefully picked out. And as for because the mice will, I don't pretend to know 07:42.000 --> 07:48.480 what Lana needs on his laptop, so, right? Yeah, I mean system D, yeah, needs to be on there, 07:49.440 --> 07:53.280 I don't know what packages he needs or whatever, so I'm not going to pretend I can know, 07:53.280 --> 07:57.840 so it's just needs to be customizable, so that if anything's missing Lana can just add it himself, 07:58.400 --> 08:03.120 customize whatever it wants, so that he's happy with the system. And of course, while Lana 08:03.120 --> 08:08.320 does extremely afraid of evil mates, he says, so we need to do the secure measure, put it to make 08:08.320 --> 08:14.480 sure that he can sleep soundly at night. So then we get to particle of us, which is basically 08:14.640 --> 08:19.440 the implementation of all this requirements. It's in a mutable image-based distribution, 08:19.440 --> 08:24.960 like, again, all the stuff, Lana wants really. It's a mutable in the way that slice user is 08:24.960 --> 08:30.960 immutable, at sea, and the root partition is the encrypted, of course, but writable, and then 08:30.960 --> 08:37.520 slice user is redownly the invariant, like the way Lana has described it in countless of talks, 08:38.960 --> 08:43.280 as well using make-away size, so like why it's a system D tool, it uses a bunch of other 08:43.360 --> 08:48.480 sets in the tool, so we use it, because we know it, and it forces us to do extra dark fooding. 08:49.760 --> 08:53.600 There's an odd version, because I like arch, there's a fedora version, because fedora, 08:53.600 --> 09:00.240 a letter of likes fedora. We have GD and no, again, Lana likes no, I like GD, so there's still other 09:00.240 --> 09:07.520 versions. And then it's self-signed, so this is where it starts to differ a bit from the regular 09:07.600 --> 09:13.440 or other immutable distributions. The other immutable distributions are very much focused on being 09:14.880 --> 09:20.240 something that is built somewhere on a built machine in the cloud, or like on a server somewhere, 09:20.240 --> 09:25.920 and then you download it, with, I don't know if any, in the world's version already completely 09:25.920 --> 09:30.800 does this actually, but the idea is that you get the key from the fan there, the sine and key, 09:30.800 --> 09:35.920 you enroll that into your UEFI firmware, or you get these small quinnets, like with the whole shimting. 09:37.920 --> 09:42.720 Which is not great, but the problem with that is that you can control what goes into the 09:42.720 --> 09:50.480 image that way, because it's all signed by the distribution. With this, with this, we do self-signing, 09:51.760 --> 09:57.520 so that you sign it, which means you control what goes in it. So you get full control, 09:57.520 --> 10:03.600 like you customize the image, however you want, you sign it yourself, and your computer will only run 10:03.600 --> 10:08.240 the stuff that you sign, and not whatever the distribution sign. So you get back some, I think you 10:08.240 --> 10:12.800 get back on troll, I don't think when we, like the whole world seems to be moving towards 10:12.800 --> 10:18.640 immutable distributions, but I don't think we want to end up in a place where we're all using 10:18.640 --> 10:24.160 distribution keys in our emrolling distribution keys. I think we always want to make it possible for 10:24.160 --> 10:30.800 users to sign things themselves, so that they retain full control if they want to do so. 10:30.880 --> 10:35.680 I don't think the vendor provided key sting is bad, I just need to think we need to make sure that 10:35.680 --> 10:41.600 the other way is also always possible, otherwise you can end up in like awkward and not great situations. 10:42.640 --> 10:46.400 And so, like I said, you build it yourself. So you don't download the image, 10:47.840 --> 10:53.440 when there's an update, you build the update yourself on the system, and then install it, reboot, 10:53.440 --> 10:59.520 and you get into the new version. That's where we're developing this stuff. 11:00.480 --> 11:05.600 So basically, it's a wrapper with a giant make or second configuration that sets all of this up, 11:06.160 --> 11:12.000 and with a documentation on how to install it. So let's take a look at some workflows 11:12.000 --> 11:16.800 to make concrete how you would start running this stuff. Installing make a size as simple as 11:16.800 --> 11:23.920 clone the wrapper, put it in your path, and you can use it. Free deployment. So you have an existing 11:23.920 --> 11:30.080 laptop, you want to build the image to install on any device, right? Let's stop laptop or whatever. 11:31.520 --> 11:36.400 Clone particle OS added make or set a local account, that's where you can put all the 11:36.400 --> 11:40.400 customizations. So any make or size setting, you can just configure where you add packages, 11:40.400 --> 11:43.600 you add files, you switch the file system, whatever you can think of, you can do it. 11:44.560 --> 11:51.040 Build the image, then you end up with DDI with three partitions. So the ESP is there with the 11:51.040 --> 11:58.560 signed UKI in it. You have the Verity partition for slash user, and you have the actual slash 11:58.560 --> 12:04.320 user partition itself with your image in it. No route partition or anything that's created on 12:04.320 --> 12:10.240 first boot and locked against the TPM the way, let us like once it. And then we have like a 12:10.240 --> 12:16.400 burnt command to just like it's basically, it's a DDI but a little smart. And then you get it on 12:16.480 --> 12:22.880 you to your USB right away. Actually installing it the first thing you do is you set a UFI password. 12:23.600 --> 12:27.840 If you don't, the entire thing is pretty much useless because like an attacker will just 12:27.840 --> 12:33.040 go into the BIOS disabled secure boot and what's the point. So you need a UFI password. 12:34.080 --> 12:39.760 You need to put secure boot and set up mode. Set up mode is basically, it gets rid of the existing 12:39.760 --> 12:43.360 keys and puts the secure boot and a state where new keys can be enrolled. 12:44.000 --> 12:49.360 Once you do that, you boot from the USB. There will be a, you'll get it to a system 12:49.360 --> 12:55.600 deboot. There will be a very nice and roll secure boot keys menu entry. You select that 12:55.600 --> 12:59.520 and system deboot will automatically, well, not automatically. The other one will roll the secure 12:59.520 --> 13:04.880 boot keys for you into the system. Again, do this automatically, but there's a lot of horrible 13:04.880 --> 13:10.480 UFI firmware out there. So we don't do this by default, right? We make it a explicit choice. 13:11.120 --> 13:16.800 It will tell you that this might break your system. In this case, it won't, but I'm going to be safe. 13:18.000 --> 13:22.240 And then you have secure boot setup. That means you can select the install of UFI for 13:22.240 --> 13:29.840 FunX and it'll load. The installer mode is basically meant for USBs, like it's not. So the 13:29.840 --> 13:34.640 image is on a USB, but it's not to find all destination where you want to install it. So you boot 13:34.640 --> 13:39.520 into the installer UFI profile, which means that wood partition all that stuff doesn't get created. 13:39.600 --> 13:44.560 You just get into a shell where you can actually install it to the disk you want it to. So 13:44.560 --> 13:49.760 it'll auto lock you in this route and you can just run system deboot after that to actually deploy 13:50.800 --> 13:57.920 the image to the disk that you want to own. That is right because that array is your drive. We don't 13:58.960 --> 14:03.760 tool boot yet. They're installing to existing systems. So currently you have to erase what 14:04.400 --> 14:10.720 is on a disk to be able to install this. And then you reboot. And then this is what your 14:11.840 --> 14:15.760 disk will look like. So we have those first three partitions that are 14:15.760 --> 14:19.680 were in the image. Those just got copied to the target disk. And then we created the whole bunch of new 14:19.680 --> 14:26.640 partitions. A very partition and another use partition. So those are the B partitions. Right, 14:26.640 --> 14:32.000 this is an A, B setup. You install to the B partition, the update. And now you switch to it. 14:32.960 --> 14:36.560 So our partition I created, I created it against the TPM wood partition. I created it against the 14:36.560 --> 14:43.440 TPM and the separate home partition to be used with not encrypted but to be set up to be used with 14:43.440 --> 14:51.600 the system deholding. First boots, I mean pretty simple. You select the regular UKI profile 14:52.160 --> 14:58.080 system de first boot runs, asks you a bunch of questions, a couple first boot runs and sets up your 14:58.160 --> 15:04.560 home for your regular user. You log in. You change your bunch of home de-settings because the 15:04.560 --> 15:10.480 defaults will horribly break and absolutely not work at all. I got locked out of my home five times 15:10.480 --> 15:16.480 trying to get this to work. So there's some bucks to face there. But for now we change all 15:16.480 --> 15:21.040 bunch of settings and then it does work. And then you enable your display manager of choice. So 15:21.040 --> 15:26.160 SDDM for KDE or KDM for dome and then it's installed. Then you log in and you get into your 15:26.160 --> 15:32.880 desktop environment and you can set up the thing the way you like it. How to hack on system de. 15:32.880 --> 15:39.840 So the base image is immutable. So no compiler, no mess on or whatever in there. The bigger the 15:39.840 --> 15:44.480 base image get, the longer update stake. So you don't want to make it too big. So what other 15:44.480 --> 15:47.520 immutable distributions do is like this for a box or containers or whatever to do all their 15:47.520 --> 15:55.360 development. That means OCI, if you say OCI, Leonard runs away. So that doesn't work. So I 15:55.440 --> 15:59.680 implement something and make our site to basically do the same thing. Right. It's a sandbox where 15:59.680 --> 16:05.520 you can install all the development tools you need. So it does it automatically. So if you 16:05.520 --> 16:09.920 do run that in the system de-repo, it'll just download all the stuff you need and you can run it from 16:09.920 --> 16:17.280 there. And then right, you do development with make our sciences in the S usual. You spawn 16:17.280 --> 16:23.600 of the M and then you can test changes. And then the final one is update. So you added that 16:23.600 --> 16:29.120 make us add a local confer file again. At the back of the package, you want to build the update 16:29.120 --> 16:34.320 and then you want to make our sciences update updates, which will install to the B partitions. 16:34.320 --> 16:38.880 Right. We are empty on the first update and then the old version on when you do it the next time. 16:40.240 --> 16:47.680 It will copy the UGI to the ESP. And that's it. That's the update. So it should be a 16:47.680 --> 16:53.200 very atomic. And of course there's a B partitions. So if the new update doesn't work, 16:53.200 --> 16:58.320 you can always go back to the old version. And report a book or I don't know. 16:59.920 --> 17:05.280 Then yeah. So reboot to get into the update. So this is like important. It's not like the 17:05.280 --> 17:09.520 enough of great where you're just upgrade and then continue using it. Each update requires a reboot. 17:10.240 --> 17:15.600 So what I've noticed is that I update last because of the means means reboot. Like I don't know. 17:15.600 --> 17:20.400 We probably need to do something about this eventually. But because having to reboot for each update 17:20.720 --> 17:25.840 is kind of annoying. But it works. You just end up updating less than usual. 17:26.880 --> 17:31.280 So what do we end up with on this laptop? Of course because it would be extremely 17:31.280 --> 17:37.280 hypocritical to be able to hack a laner about not using all of this stuff and then do this presentation 17:37.280 --> 17:41.360 from a laptop that's not using all of this stuff either. So this is running quite a close. 17:42.000 --> 17:47.520 It has been for a few months and we end up using all of these things. So no piece of our 17:48.480 --> 17:55.600 yet because I have no clue how to set it up. Later it needs to tell me. Then we can probably 17:55.600 --> 18:00.560 enable PCR log as well or at least I hope. And then we don't use all the extensions stuff yet 18:00.560 --> 18:05.120 either because you built the image locally and you are full control over it. So there's no real 18:05.120 --> 18:10.160 point in the extensions. So like we still need to figure something out for that. 18:11.200 --> 18:15.680 Does it work? Yeah. I find for questions insist and the I report them and they get fixed. So that's great. 18:16.640 --> 18:20.960 Not really. There's also a lot of questions that are stuff that doesn't work that doesn't get fixed. 18:20.960 --> 18:26.480 So that's whatever. But I have found regressions and they were fixed. So it is helping that way. 18:29.200 --> 18:33.360 Call to action for laner. Let's focus on building end-to-end solutions. Don't just merge the API 18:33.360 --> 18:38.080 insist and also get it running a particle of S so that we are actually using it. 18:39.200 --> 18:44.160 Let's make sure we consume our own API immediately. Edo ourselves or a user. 18:45.920 --> 18:52.640 Switch to particle OS. What's missing? Luca is working on building these images in a build system. 18:53.600 --> 18:57.600 Still needs a lot of work. But then you could actually download the update instead of building it yourself. 18:58.720 --> 19:01.840 That's the part that's going to for stock footing of all the extensions stuff because then it's 19:01.840 --> 19:06.480 signed by a vendor key. You can modify it locally immediately anymore. So that will help us get 19:06.480 --> 19:10.800 to stock footing for that part. Right? PCR log I mentioned. Add more distributions. We have 19:10.800 --> 19:16.400 action for Dora. But of course I want to add more if I'm sure some people would love a 19:16.400 --> 19:22.000 double inversion. Desktop environments eventually do a boot and get laner to use this. 19:23.120 --> 19:24.400 Basically the stock is this. 19:31.520 --> 19:33.680 That was the end. Happy to answer any questions. 19:40.800 --> 19:53.440 This is probably a question for laner more than me. 19:55.200 --> 19:59.920 I mean you can do that but I think ultimately the wallets should probably be unlocked by 20:01.200 --> 20:05.520 some key that's derived from here from directory and I've been talking to 20:05.520 --> 20:11.120 people about this. What they wanted to do is that they're in a very ideas. 20:12.160 --> 20:15.440 But it's more important that you haven't even talked earlier than that where it was talking about 20:15.440 --> 20:20.880 user credentials. It doesn't make sense. That's kind of what they want to use that. 20:22.880 --> 20:24.320 It doesn't should have happened. 20:28.160 --> 20:32.160 Is there any pre-boots and integration? 20:32.800 --> 20:37.600 Like the effects of the system like the system failed and then the first time to deal with it? 20:37.600 --> 20:42.240 So there is a target. Is there any automatic rollback? 20:42.240 --> 20:47.840 Yes. I know there is a target for this and system the first. 20:47.840 --> 20:49.280 Which one was the name again? 20:49.280 --> 20:55.600 The last boot. Yes. So you can order stuff before that and then if it fails it'll do the rollback. 20:55.600 --> 21:01.600 And we have boot counting set up. In part of the OS but we don't order anything before 21:01.920 --> 21:07.120 boot again already. So I don't know if we have any stuff already that is order before that that 21:07.120 --> 21:09.200 will rollback if it fails. 21:14.000 --> 21:18.720 So it's there but it's probably pretty basic and could be extended a lot more. 21:19.520 --> 21:21.200 But you can always do it manually of course. 21:31.600 --> 21:36.400 Yes. So that's the part that looks like the system and so if you win you as an update on the 21:36.400 --> 21:42.480 update system you will be able to do it after that and you can do the update. 21:43.520 --> 21:50.240 And so we use those things to move into the course as we use for the judge's decisions. 21:51.200 --> 22:10.480 So the first one is if you have an infected commutable system then if you build the update on 22:10.480 --> 22:15.680 the system itself it'll also be or there's a good chance it'll also be infected. 22:15.680 --> 22:18.080 So how do we get rid of that? 22:18.080 --> 22:23.520 So that first and then we'll get to the second part. So I think the idea there is that we have factory 22:23.520 --> 22:29.360 reset. So if you have an infected system then in this case you would have to do a complete factory 22:29.360 --> 22:37.040 reset to get rid of all state but keep the you can keep the all the measured or all the trusted 22:37.040 --> 22:42.080 stuff like your slash user but all the rest goes away and then you start from scratch. 22:42.800 --> 22:48.000 And then the second question was does it also make sense to get a default version that is 22:48.560 --> 22:52.640 provided by the distribution of the or an image that's provided by the distribution and so the 22:52.640 --> 22:59.920 answer is yes and that's basically the part that look as working on. It's not trivial for existing 22:59.920 --> 23:05.120 build systems to actually be able to do this signing. So we're trying to get this working in the 23:05.120 --> 23:11.120 open-suced build system which is offline signing so you can sign when you're doing the image 23:12.000 --> 23:18.160 it's a completely separate async process. So the entire build process has to be modified to 23:19.920 --> 23:24.560 extract all the data that needs to be signed without actually signing it then get it signed by 23:24.560 --> 23:31.680 completely different thing. Get those inputs back and then insert them into the into the image. 23:31.680 --> 23:36.800 This is a very different workflow than what you usually do which is you sign when you need to 23:36.800 --> 23:44.480 in the build process itself. So we need to do quite a few horrible changes. Yeah he is doing all 23:44.480 --> 23:47.840 the hacks required to make that work but we'll get that eventually I think. 24:06.800 --> 24:36.560 So the use case is when you have the vendor signed image. Oh yeah the 24:36.560 --> 24:42.080 well how do it says x fit into the to the picture presented here was the question. So 24:43.440 --> 24:48.480 says x are for like when you build like I said with OBS. If you build it on OBS then the key 24:48.480 --> 24:53.280 then you have vendor signed key or vendor provided key. So then you can modify it all locally. 24:53.280 --> 24:57.840 So then you're kind of forced to use the extensions because you can sign those locally with your own 24:57.840 --> 25:02.880 key which then has to be enrolled with markers something like that and then that's where those things 25:02.880 --> 25:09.280 become required. That's for if you want to build your own additions locally but what's also possible 25:09.280 --> 25:16.480 of course is that the distribution itself provides a pre-build set of says x which are much more 25:16.480 --> 25:22.080 coarse than packages. So there would be a lot more in each says x you would have a lot fewer of them 25:22.080 --> 25:25.360 but you could then install instead of installing your package you would install a says x for 25:25.360 --> 25:30.880 the specific functionality you need and that allows you to keep the base image small because you don't 25:30.960 --> 25:36.160 have to put everything in it but then you can apply specific says x to get the functionality that 25:36.160 --> 25:40.400 you need as a user. So it's kind of similar but it would never be as fine grain as packages. You're 25:40.400 --> 25:45.600 never going to have like thousands of bag out of says x you would have the idea to have much for you.