WEBVTT 00:00.000 --> 00:02.680 When you're a in a 00:02.840 --> 00:07.320 work you're a 00:07.600 --> 00:08.640 www.Priö Hopkins.com 00:09.400 --> 00:19.940 Sounders, Alan, 00:22.680 --> 00:25.120 going to tell us 00:26.080 --> 00:28.800 everything about what we need to do to 00:28.800 --> 00:31.200 And not great. 00:31.200 --> 00:36.480 So then let's go to who wants their distribution or themselves 00:36.480 --> 00:38.880 to use all the stuff that Lena was talking about 00:38.880 --> 00:40.440 in a C-TM talk. 00:40.440 --> 00:41.640 All right, that looks pretty cool. 00:41.640 --> 00:43.440 Who is actually using this stuff that Lena 00:43.440 --> 00:45.200 is talking about in a C-TM talk? 00:50.200 --> 00:53.600 No, not very great. 00:53.600 --> 00:57.920 So lots of people want to use it, not many are using it yet. 00:58.800 --> 01:00.760 But before you actually start using it, 01:00.760 --> 01:02.560 we need to talk. 01:02.560 --> 01:04.040 We need to have a chat. 01:04.040 --> 01:07.240 We need to talk about dark fooding. 01:07.240 --> 01:08.400 What is dark fooding? 01:08.400 --> 01:12.000 It's the act of using your own software. 01:12.000 --> 01:16.520 What is the state of dark fooding in system D then? 01:16.520 --> 01:18.600 It's a good question to ask, right? 01:18.600 --> 01:21.360 And so let me start with just a picture. 01:21.360 --> 01:25.840 From the secret internal system D maintain a chat. 01:25.840 --> 01:29.360 Like this comment that you're using RunZero and not Zero anymore. 01:29.360 --> 01:31.960 18th yet, only one of them actually 01:31.960 --> 01:33.680 liked it, which was mean. 01:33.680 --> 01:37.360 So we have this RunZero thing to replace Zero, 01:37.360 --> 01:40.520 but is any system you maintain actually using it? 01:40.520 --> 01:41.800 I don't know. 01:41.800 --> 01:43.840 Ah, there we go. 01:43.840 --> 01:46.160 Not yet. 01:46.160 --> 01:48.240 Of course, RunZero is one tool. 01:48.240 --> 01:51.640 So I mean, it's not a proper measurement of whatever 01:51.640 --> 01:52.480 dark fooding correctly. 01:52.480 --> 01:58.280 So there's a list of Linux inventions, right? 01:58.280 --> 02:00.040 As you know, if I can't limit it, the old stuff, 02:00.040 --> 02:03.120 GPT Auto, and then the new stuff, PCR lock, 02:03.120 --> 02:08.240 and all the other stuff, Linux has invented over the years. 02:08.240 --> 02:10.440 It's not all of them. 02:10.440 --> 02:13.120 And the list might have been chosen to make them look 02:13.120 --> 02:15.640 bad, but we'll see that in the next slide. 02:15.640 --> 02:16.680 So let's take a look. 02:16.680 --> 02:21.360 Like what is Linux actually using according to my guess? 02:21.360 --> 02:24.560 I think it looks like this. 02:24.560 --> 02:28.960 So RunZero's stock for door workstation installed last time 02:28.960 --> 02:32.880 I asked, which is, sure, Yavkrab set up, 02:32.880 --> 02:35.360 because for door doesn't encrypted with this, 02:35.360 --> 02:37.720 he uses HomeD, he didn't know that. 02:37.720 --> 02:40.080 And he gets rid of Krab as well, and replaces it with 02:40.080 --> 02:41.200 systemly food. 02:41.200 --> 02:43.000 So that are the good things. 02:43.000 --> 02:46.440 But then the other stuff is not really used at all. 02:46.440 --> 02:52.760 Yeah, to develop, but not to manage your system. 02:52.760 --> 02:57.680 Yeah, so RunZero, PCR lock, and unify-conlimit, 02:57.680 --> 03:01.040 so I wasn't sure, are you using unify-conlimit, just? 03:01.040 --> 03:02.840 For a run, maybe I could put enough. 03:02.840 --> 03:05.480 For the actual, yeah, for the list for door, it doesn't do it, right? 03:05.480 --> 03:08.120 So that goes rather, PCR lock, I guess, isn't used either. 03:08.120 --> 03:11.320 So that's for that, so I'll put RunZero screen. 03:11.320 --> 03:13.960 So the overall conclusion is, like, there's a lot more 03:13.960 --> 03:15.760 wet than there is green, right? 03:15.760 --> 03:18.880 Which is not great. 03:18.880 --> 03:20.360 Of course, we can just single out Leonard. 03:20.360 --> 03:24.720 So I'll ask to answer some other systemly maintenance, as well. 03:24.720 --> 03:26.760 Look, I'm using Unifactor, could I know what 03:26.760 --> 03:28.040 I'm using on a laptop? 03:28.040 --> 03:30.560 I know that Zibigno is using MakeOSI-init ID, 03:30.560 --> 03:33.640 so makeOSI becomes yellow, because makeOSI-init ID 03:33.640 --> 03:36.000 is only a little bit of the all the stuff you can do 03:36.000 --> 03:37.440 with MakeOSI. 03:37.440 --> 03:40.080 I know Mike is using system the Alper generator 03:40.080 --> 03:41.720 and credentials. 03:41.720 --> 03:45.400 So it's a little better, but still a lot of rats, right? 03:45.400 --> 03:46.840 Nobody's using Zibigno. 03:46.840 --> 03:50.120 Nobody's using signed PCR policies on the laptop. 03:50.120 --> 03:54.400 And the extension stuff isn't really being used either, 03:54.400 --> 03:57.840 because, again, by wood, you have a rideable user 03:57.840 --> 04:01.160 partition, so you just DNF upgrade to get your updates. 04:01.160 --> 04:04.640 There's no need for all the extension stuff. 04:04.640 --> 04:06.520 Why is this problem? 04:06.520 --> 04:09.960 So what happens is we merge a lot of new stuff 04:09.960 --> 04:13.880 with public APIs, but there's nothing immediately 04:13.880 --> 04:16.320 using that stuff. 04:16.320 --> 04:20.520 The public API then goes into this in a stable release. 04:20.520 --> 04:22.520 And we guarantee backwards compatibility. 04:22.520 --> 04:25.760 So once that happens, we can't change it anymore. 04:25.760 --> 04:27.480 We wait a little while. 04:27.480 --> 04:29.480 Someone tries to actually use the interface, 04:29.480 --> 04:32.400 and it turns out it doesn't exactly do what's needed, 04:32.400 --> 04:35.440 or needs changes, or it's just incomplete. 04:35.440 --> 04:38.120 It's not often that the interface is wrong, 04:38.120 --> 04:40.520 most of the time it's just incomplete, 04:40.520 --> 04:44.280 and there's, like, you find out as some important thing 04:44.280 --> 04:47.840 is missing for you to be able to use it effectively. 04:47.840 --> 04:50.960 And then we have to figure out how to either fix the interface 04:50.960 --> 04:53.000 or just complete it. 04:53.000 --> 04:54.080 This is pretty generic. 04:54.080 --> 04:56.680 Like what it actually ends up looking like in practice, 04:56.680 --> 04:59.720 is that, Lana, this is one merging all these public APIs. 04:59.720 --> 05:01.800 I'm the one trying to use them. 05:01.800 --> 05:05.440 I find out it doesn't work, and I have to complete them. 05:05.440 --> 05:07.400 Not amazing. 05:07.400 --> 05:10.120 So how do we make Lana talk with system D, 05:10.120 --> 05:12.520 or in other words, how do we make Lana 05:12.520 --> 05:16.200 to his own consumer of his own stuff? 05:16.200 --> 05:19.760 It seems that the duration is fine. 05:19.760 --> 05:22.000 It seems that the situation is fine. 05:22.000 --> 05:24.360 Yeah. 05:24.360 --> 05:25.800 So all we need to do is, of course, 05:25.800 --> 05:28.200 it's great, it's system D's own distribution rights. 05:28.200 --> 05:30.360 Like we reject the Unix philosophy, 05:30.360 --> 05:32.480 right, we've stolen DNS, we've stolen network, 05:32.480 --> 05:34.280 we've stolen in it, we still have everything, 05:34.280 --> 05:37.080 so why not steal the distribution as well? 05:37.840 --> 05:38.880 That was a choke. 05:42.480 --> 05:44.080 So what would you do for Roly? 05:44.080 --> 05:47.680 Yeah, this slide is the one I expect to come on for our Unix, 05:47.680 --> 05:52.680 but we'll see, we can't reinvent the entire real one we do this, 05:52.680 --> 05:56.320 why it's just me, I don't have time to repackage the world. 05:56.320 --> 05:58.680 So we need to reinvent the real a little bit, 05:58.680 --> 06:01.960 but not completely, otherwise it will never get done. 06:01.960 --> 06:04.880 It needs to be known because Lana doesn't know him, person. 06:04.880 --> 06:08.400 So if it doesn't have no one, we'll never get Lana to use it. 06:08.400 --> 06:10.880 It has to use as many system D tools as possible, 06:10.880 --> 06:12.960 because if we're not using system D tools to build it, 06:12.960 --> 06:17.040 then we're not getting the dog feeding in the first place. 06:17.040 --> 06:18.640 The more system D tools we use, 06:18.640 --> 06:21.920 the more we exercise the interfaces and the implementation, 06:21.920 --> 06:24.720 the more bugs we find, which I hopefully 06:24.720 --> 06:27.520 fixed before it gets into the hands of users, 06:27.520 --> 06:30.960 instead of after it gets into the hands of users. 06:30.960 --> 06:36.080 Using all the system D tools is in itself not enough, 06:36.080 --> 06:38.720 because if we package this with a system D, 06:38.720 --> 06:41.840 or if they use a system D stable release in this distribution, 06:41.840 --> 06:45.280 or at least in the version of it that Lana will run, 06:45.280 --> 06:46.560 it's too late, right? 06:46.560 --> 06:48.240 The public APIs we've been merged already, 06:48.240 --> 06:50.800 backwards compatibility, and we can fix them. 06:50.800 --> 06:53.840 So it has to run system D from straight from get main, 06:53.840 --> 06:59.120 so that we can immediately start using the new public APIs in the distribution, 06:59.120 --> 07:01.360 exercise them, make sure they work, 07:01.360 --> 07:04.800 fix them if they don't work, before we're tied 07:04.800 --> 07:07.440 by backwards compatibility. 07:07.440 --> 07:11.760 And we have to enable easy acting on system D and the distribution itself, 07:11.760 --> 07:13.760 because we run Lana to run this, 07:13.760 --> 07:15.600 Lana needs to be able to hang on system D, 07:15.600 --> 07:18.640 so this needs to make that possible. 07:18.640 --> 07:22.400 We also run Lana ideally, not to just work on system D, 07:22.400 --> 07:27.120 but also implement all the stuff he adds to system D in the distribution, 07:27.120 --> 07:30.080 so that we have the end-to-end thing completed, 07:30.080 --> 07:34.160 and he gets to immediately consume the API C adds, 07:34.160 --> 07:38.960 instead of waiting for any distribution to eventually hopefully picked out. 07:38.960 --> 07:40.800 And as to because the MIs will, 07:40.800 --> 07:44.560 I don't pretend to know what Lana needs on his laptop, 07:44.560 --> 07:46.240 so, right? 07:46.240 --> 07:49.040 Yeah, I mean system D needs to be on there, 07:49.040 --> 07:51.840 but I don't know what packages he needs or whatever, 07:51.840 --> 07:53.280 so I'm not going to pretend I get no, 07:53.280 --> 07:55.280 so it's just needs to be customizable, 07:55.280 --> 07:58.240 so that if anything's missing, Lana can just add it himself, 07:58.240 --> 08:02.080 because much, whatever it wants, so that he's happy with the system. 08:02.080 --> 08:03.680 And of course, while Lana does it, 08:03.680 --> 08:05.760 extremely afraid of evil mates, he says, 08:05.760 --> 08:10.240 so we need to do secure a measure, put it to make sure that he can sleep soundly at night. 08:12.080 --> 08:13.840 So then we get to particle of us, 08:13.840 --> 08:16.320 which is basically the implementation of all this requirements. 08:17.360 --> 08:19.360 It's an immutable image-based distribution, 08:19.360 --> 08:22.080 like, again, all the stuff, Lana wants really. 08:22.320 --> 08:25.520 It's a mutable in the way that slice user is immutable, 08:26.560 --> 08:29.440 at sea, and the root partition is the encrypted, of course, 08:29.440 --> 08:32.800 but writable, and then slice user is redownly, 08:32.800 --> 08:37.520 the invariant way Lana has described it in countless of talks. 08:38.960 --> 08:40.320 It's very using make-away size, 08:40.320 --> 08:44.000 so it's a system D tool, it uses a bunch of other system D tools, 08:44.000 --> 08:48.400 so we use it, because we know it, and it forces us to do extra dark fooding. 08:49.360 --> 08:52.720 There's an odd version, because I like arch, there's a fedora version, 08:52.720 --> 08:56.560 because fedora likes fedora, we have GD and no, 08:56.560 --> 09:00.640 again, Lana likes no, I like GD, so there's still a lot of verdens. 09:01.760 --> 09:05.760 And then it's self-signed, so this is where it starts to differ a bit 09:05.760 --> 09:10.240 from the regular or immutable distributions. 09:10.240 --> 09:13.440 The other immutable distributions are very much focused on being 09:14.400 --> 09:18.720 something that is built somewhere on the built machine in the cloud, 09:18.720 --> 09:21.280 or like on a server somewhere, and then you download it, 09:22.400 --> 09:26.400 with, I don't know if any double this version already completely does this, 09:26.400 --> 09:30.800 actually, but the idea is that you get the key from the fan there, the signing key, 09:30.800 --> 09:35.920 you enroll that into your UEFI firmware, or you give you small quinnets, like with the whole shimting, 09:37.920 --> 09:43.200 which is not great, but the problem with that is that you can control what goes into the image that 09:43.760 --> 09:50.480 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:07.920 the stuff that you signed, and not whatever the distribution sign, so you get back some, 10:07.920 --> 10:12.800 I think you get back control, I don't think when we, like the whole world seems to be moving towards 10:12.800 --> 10:18.720 a mutable distributions, but I don't think we want to end up in a place where we're all using 10:18.720 --> 10:24.000 distribution keys, in our own rolling distribution keys, I think we always want to make it possible 10:24.000 --> 10:30.800 for users to sign things themselves, so that they retain full control, if they want to do so. 10:30.800 --> 10:35.680 I don't think the vendor provided key 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.560 --> 10:46.400 And so, like I said, you build it yourself, so you don't download the image, 10:47.760 --> 10:53.440 when there's an update, you build the update yourself on the system, and then install it, reboot, 10:53.440 --> 11:01.680 and you get into the new version. That's where we're developing this stuff, so it's basically 11:01.680 --> 11:06.800 I, it's a rapper with a giant make-or-cycle configuration that sets all of this up and with a 11:06.800 --> 11:12.320 documentation on how to install it. So let's take a look at some workflows to make 11:12.320 --> 11:16.720 concrete how you would start running this stuff, while installing make-or-cycle simplest, 11:16.720 --> 11:23.920 clone the rapper, 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, a desktop laptop or whatever, 11:30.320 --> 11:36.400 clone particle OS, edit make-or-cycle local accounts, that's where you can put all the 11:36.400 --> 11:40.400 customizations. So any make-or-cycle setting, you can just configure where you add packages, 11:40.400 --> 11:43.600 you add files, you switch the files system, whatever you can think of, you can do it, 11:44.640 --> 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.480 signed UKEI in it. You have the variety partition for slash user, and you have the actual slash 11:58.480 --> 12:04.640 user partition itself with your image in it. No vote partition or anything that's created on first 12:04.640 --> 12:10.800 put, and locked against the TPM the way, I don't like once it, and then we have like a burn command 12:10.800 --> 12:17.200 to just like it's basically, it's a DDI but a little smart, and then you get it on it to your USB, 12:17.200 --> 12:22.320 be a variety of translation. Actually installing it the first thing you do is you set a UKEI 12:22.320 --> 12:27.840 password. 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 disable secure boot and what's the point, so you need a UKEI bypass. 12:34.080 --> 12:39.360 You need to put secure boot and set up mode, set up mode is basically, right, gets rid of the 12:39.360 --> 12:45.840 existing keys and puts the secure boot and a state where new keys can be enrolled. Once you do that, 12:45.840 --> 12:51.360 you boot from the USB. There will be a, you'll get it to a system reboot. There will be a 12:51.360 --> 12:56.880 very nice and roll secure boot keys menu entry. You select that and system reboot will automatically, 12:56.880 --> 13:02.000 well, not automatically. The other one will roll the secure boot keys for you into the system. 13:02.000 --> 13:07.040 Again, do this automatically, but there's a lot of horrible UKEI firmware out there, so we don't 13:07.040 --> 13:12.800 do this by default, right? We make it a explicit choice. It will tell you that this might break 13:12.880 --> 13:19.840 your system, in this case it won't, but it's got to be safe. And then you have secure boot setup. 13:19.840 --> 13:26.240 That means you can select the install of UKEI for the next and it'll load. The installer mode is basically 13:27.360 --> 13:33.040 meant for USB, like it's not, so the image is on a USB, but it's not to find all destination where you 13:33.040 --> 13:37.520 want to install it. So you boot into the installer UKEI profile, which means that wood partition 13:37.520 --> 13:42.720 and all that stuff doesn't get created. You just get into a shell where you can actually install 13:42.720 --> 13:47.200 it to the disk you want it to. So it'll auto lock you in this route and you can just run 13:47.200 --> 13:52.720 system de-report after that to actually deploy the image to the disk that you want it to own. 13:55.200 --> 13:59.760 That is what, because that arrays is your drive, right? We don't do tool boot yet, 13:59.760 --> 14:04.960 they're installing to existing systems, so currently you have to erase whatever is on that disk 14:04.960 --> 14:10.720 to be able to install this. And then you reboot, and then this is what your 14:11.760 --> 14:16.560 disk will look like. So we have those first three partitions that are, of where in the image, 14:16.560 --> 14:20.160 those just got copied to the target disk and then we created the whole bunch of new partitions. 14:21.600 --> 14:27.200 A very partition, and another use partition. So those are the B partitions, right? This is an 14:27.200 --> 14:32.000 AB setup. You install to the B partition, the update, and I use switch to it. 14:32.960 --> 14:37.680 So our partition I created, I created it against the TPM boot partition, I created it against the TPM, 14:37.680 --> 14:43.440 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 de-home. First boot, I mean pretty simple, you select the regular UKI profile, 14:52.160 --> 14:58.320 system de-first boot runs, asks you a bunch of questions, a couple first boot runs, and sets up your home 14:58.960 --> 15:05.040 for your regular user, you log in, you change your bunch of home de-settings, because the defaults 15:05.040 --> 15:10.640 will horribly break, and absolutely not work at all. I got locked out of my home five times trying 15:10.640 --> 15:16.800 to get this to work, so there's some bucks to face there. But for now, we change all bunch of 15:16.800 --> 15:21.200 settings, and then it does work, and then you enable your display manager of choice. So as 15:21.200 --> 15:26.080 the DM for KDE or KDM for a dome, and then it's installed, right? Then you log in and you get into 15:26.080 --> 15:32.880 your 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.440 so the base image is immutable, so no compiler, no mess on or whatever in there, right? The 15:39.440 --> 15:44.240 bigoted base image gets a longer update stake, so you don't want to make it too big. So what 15:44.240 --> 15:47.440 other immutable distributions do is like this for a box or containers, whatever, to do all the 15:47.440 --> 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.040 there. And then, right, you do development with make our sciences, and the S usual, right? You 16:17.040 --> 16:23.600 spawn of EM, and then you can test changes. And then the final one is update, so you added that 16:23.600 --> 16:29.440 make us add a local confer file again, add by the practice one, build the update, and then you 16:29.440 --> 16:35.520 run make our sciences update updates, which will install to the B partitions, right? We are empty 16:35.520 --> 16:41.760 on the first update, and then the old version on when you do it the next time. It will copy the 16:42.320 --> 16:51.040 UGI to the ESP, and that's it, that's the update, so it should be very atomic. And of course, 16:51.040 --> 16:54.640 there's a B partitions, so if the new update doesn't work, you can always go back to the old version, 16:55.920 --> 17:03.680 and report a book, or I don't know. Then, yeah, so reboot to get into the update. So this is 17:03.680 --> 17:08.080 like important, it's not like the NF upgrade, where you're just upgrade, and then continue using it, 17:08.080 --> 17:14.240 each update requires a reboot. So what I've noticed is that I update last, because of that means 17:14.240 --> 17:17.600 me's a reboot. Like, I don't know, we probably need to do something about this, 17:17.600 --> 17:23.360 eventually, but because having to reboot for each update is kind of annoying, but it works, 17:23.360 --> 17:30.000 you just end up updating less than usual. So what do we end up with on this laptop? Of course, 17:30.000 --> 17:36.240 because it would be extremely hypocritical to be able to hack a laner about not using all of this stuff, 17:36.240 --> 17:40.400 and then do this presentation from a laptop that's not using all of this stuff either, so this is 17:40.400 --> 17:44.960 running quite a close. It has been for a few months, and we end up using all of these things. 17:45.600 --> 17:50.640 So, no piece of unlock that yet, because I have no clue how to set it up. 17:52.400 --> 17:57.600 Laner needs to tell me, then we can probably enable piece of unlock as well, or at least I hope, 17:57.600 --> 18:02.880 and then we don't use all the extensions stuff yet either, because you built the image locally, 18:02.880 --> 18:06.400 and you are full control over it, so there's no real point in the extensions. 18:08.080 --> 18:12.560 So, like, we still need to figure something out for that. Does it work? Yeah, I find 18:12.560 --> 18:15.680 for questions in system, the I report them, and they get fixed, so that's great. 18:16.960 --> 18:21.280 Not really, there's also a lot of questions that are stuff that doesn't work that doesn't get fixed, 18:21.280 --> 18:26.480 so it's whatever, but I have found regressions, and they were fixed, so it is helping that way. 18:29.200 --> 18:32.800 Call to action for Laner, right? Let's focus on building end-to-end solutions. Don't just 18:32.800 --> 18:38.000 merge the API in system, they also get it running a particle of S, so that we're actually using it. 18:38.960 --> 18:44.560 Let's make sure we can super-own API immediately. Edo ourselves, or I use it, and 18:45.680 --> 18:52.640 switch to particle OS. What's missing? Look, guys, 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.640 --> 19:01.840 That's the part that's going to for stock, putting 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 talk, putting for that part, might be Sherlock, I mentioned, add more distributions, we have 19:10.800 --> 19:16.240 auction for Dora, but of course I want to add more if, like I'm sure some people would love 19:16.240 --> 19:21.920 to have the inversion, desktop environments eventually do a boot and get Laner to use this. 19:23.120 --> 19:33.680 Basically, the stock is this, that was the end. Happy to answer any questions. 19:36.720 --> 19:38.000 Yeah. 19:51.680 --> 19:53.440 This is probably a question for Laner more than me. 19:55.280 --> 19:59.920 I mean, you can do that, but I think ultimately the wallets should probably be unlocked by 20:00.880 --> 20:06.480 some key that's derived from the directory, and I've been talking to a few people about this, 20:06.480 --> 20:13.200 like what they wanted to do with that. They're in ideas, but it's more of a leap, 20:13.200 --> 20:16.000 you haven't even talked earlier than this, where it was talking about user credentials, 20:16.000 --> 20:20.880 credentials, this isn't potential, that's kind of what they want to use there. 20:20.880 --> 20:34.640 Is there any free codes, boots, any integration, so that, like, it affects the system, 20:34.640 --> 20:37.600 like, a system failed, and then it refers back to the old thing. 20:37.600 --> 20:42.720 So there is a target? Yeah, so is there any, like, I guess, automatic rollback is what you're, 20:42.720 --> 20:48.960 yeah, so I know there is a target for this and system the first, which one, what's the name again? 20:49.920 --> 20:54.240 Yeah, blast boot, that's so on, yeah. So you can order stuff before that, and then if it fails, 20:54.240 --> 20:59.680 it'll do the rollback, and we have boot counting, like, set up. In part of the grass, but I don't, 20:59.680 --> 21:05.680 we don't order anything before blast boot again, already, so I don't know if we have any stuff, 21:05.680 --> 21:15.840 already, that is order before that, that will roll back if it fails. So it's there, but it's 21:15.840 --> 21:21.280 probably pretty basic and could be extended a lot more, but you can always do it manually, of course. 21:45.840 --> 22:06.400 Yes, so that's part of the look as work, oh yeah, so the question was, the first one is if you have an 22:06.400 --> 22:13.120 infected, a mutable system, then if you build the update on the system itself, it'll, I mean, it'll 22:13.120 --> 22:16.960 also be, or there's a good chance that it'll also be infected. So how do we get rid of that? 22:17.840 --> 22:22.960 I'll answer that first and I'll get to the second part. So I think the idea, the idea there is that we 22:22.960 --> 22:28.560 have factory reset, so if you have an infected system, then in this case you would have to do a 22:28.560 --> 22:34.160 complete factory reset to get rid of all state, but keep the, you can keep the, all the 22:35.600 --> 22:41.280 measured or all the trusted stuff like your slash user, but all the rest goes away and then you start 22:41.440 --> 22:47.680 from scratch. And then the second question was, does it also make sense to get a default version 22:47.680 --> 22:52.320 that is provided by the distribution of the, or an image that's provided by the distribution, 22:52.320 --> 22:59.200 and so the answer is yes, and that's basically the part that look as working on, it's not trivial 22:59.200 --> 23:04.640 for existing build systems to actually be able to do this signing. So we're trying to get this 23:04.640 --> 23:10.880 working in the open-suced build system, which is offline signing, so you can sign when you're doing the 23:10.880 --> 23:17.920 image build. It's a completely separate async process. So the entire build process has to be modified 23:17.920 --> 23:24.400 to extract all the data that needs to be signed, without actually signing it, then get it signed 23:24.400 --> 23:31.680 by completely different thing, get those inputs back, and then insert them into the, into the image. 23:31.680 --> 23:36.640 This is a very different workflow than what you usually do, which is just, you sign when you need 23:36.640 --> 23:44.320 to end the build process itself. So we need to do quite a few horrible changes, yeah, he is doing 23:44.320 --> 23:47.920 all the hacks required to make that work, but we'll get to our eventually, I think. 24:06.640 --> 24:28.640 So the use case is when you have the vendor signed image. Oh, yeah, that's a lot of 24:28.640 --> 24:37.440 the use case is when you have the vendor signed image. Oh, yeah, that's a, well, how do 24:37.440 --> 24:45.440 it says X fit into the, to the picture presented here was a question. So it says X are for like when you build, 24:45.440 --> 24:50.240 like I said with OBS, if you build it on OBS, then the key, then you have a vendor signed key, 24:50.240 --> 24:55.040 or vendor provided key, so then you can modify it all locally. So then you're kind of forced to use the 24:55.120 --> 24:59.120 extensions, because you can sign those locally with your own key, which then has to be enrolled 24:59.120 --> 25:05.360 with markers something like that, and then that's where those things become required. What is, 25:05.360 --> 25:10.160 that's for if you want to build your own additions locally, but what's also possible, of course, 25:10.160 --> 25:16.960 is that the distribution itself provides a pre-built set of CISX, which are much more course, 25:16.960 --> 25:22.080 STEM packages. So there would be a lot more in each CISX, you would have a lot fewer of them, 25:22.160 --> 25:25.840 but you could then install instead of installing a package, you would install a CISX for the specific 25:25.840 --> 25:30.880 functionality, you need it, and that allows you to keep the base image small, because you don't 25:30.880 --> 25:36.160 have to put everything in it, but then you can apply specific CISX to get the functionality that 25:36.160 --> 25:40.240 you need as a user. So it's kind of similar, but it would, it would never be as fine grain as packages, 25:40.240 --> 25:45.120 you're never going to have like thousands of bag out of CISX, you would have the idea to have 25:45.120 --> 25:48.880 much for you. I think that's all, and we have so all this time.