When you're a in a
work you're a
www.Priö Hopkins.com
Sounders, Alan,
going to tell us
everything about what we need to do to
And not great.
So then let's go to who wants their distribution or themselves
to use all the stuff that Lena was talking about
in a C-TM talk.
All right, that looks pretty cool.
Who is actually using this stuff that Lena
is talking about in a C-TM talk?
No, not very great.
So lots of people want to use it, not many are using it yet.
But before you actually start using it,
we need to talk.
We need to have a chat.
We need to talk about dark fooding.
What is dark fooding?
It's the act of using your own software.
What is the state of dark fooding in system D then?
It's a good question to ask, right?
And so let me start with just a picture.
From the secret internal system D maintain a chat.
Like this comment that you're using RunZero and not Zero anymore.
18th yet, only one of them actually
liked it, which was mean.
So we have this RunZero thing to replace Zero,
but is any system you maintain actually using it?
I don't know.
Ah, there we go.
Not yet.
Of course, RunZero is one tool.
So I mean, it's not a proper measurement of whatever
dark fooding correctly.
So there's a list of Linux inventions, right?
As you know, if I can't limit it, the old stuff,
GPT Auto, and then the new stuff, PCR lock,
and all the other stuff, Linux has invented over the years.
It's not all of them.
And the list might have been chosen to make them look
bad, but we'll see that in the next slide.
So let's take a look.
Like what is Linux actually using according to my guess?
I think it looks like this.
So RunZero's stock for door workstation installed last time
I asked, which is, sure, Yavkrab set up,
because for door doesn't encrypted with this,
he uses HomeD, he didn't know that.
And he gets rid of Krab as well, and replaces it with
systemly food.
So that are the good things.
But then the other stuff is not really used at all.
Yeah, to develop, but not to manage your system.
Yeah, so RunZero, PCR lock, and unify-conlimit,
so I wasn't sure, are you using unify-conlimit, just?
For a run, maybe I could put enough.
For the actual, yeah, for the list for door, it doesn't do it, right?
So that goes rather, PCR lock, I guess, isn't used either.
So that's for that, so I'll put RunZero screen.
So the overall conclusion is, like, there's a lot more
wet than there is green, right?
Which is not great.
Of course, we can just single out Leonard.
So I'll ask to answer some other systemly maintenance, as well.
Look, I'm using Unifactor, could I know what
I'm using on a laptop?
I know that Zibigno is using MakeOSI-init ID,
so makeOSI becomes yellow, because makeOSI-init ID
is only a little bit of the all the stuff you can do
with MakeOSI.
I know Mike is using system the Alper generator
and credentials.
So it's a little better, but still a lot of rats, right?
Nobody's using Zibigno.
Nobody's using signed PCR policies on the laptop.
And the extension stuff isn't really being used either,
because, again, by wood, you have a rideable user
partition, so you just DNF upgrade to get your updates.
There's no need for all the extension stuff.
Why is this problem?
So what happens is we merge a lot of new stuff
with public APIs, but there's nothing immediately
using that stuff.
The public API then goes into this in a stable release.
And we guarantee backwards compatibility.
So once that happens, we can't change it anymore.
We wait a little while.
Someone tries to actually use the interface,
and it turns out it doesn't exactly do what's needed,
or needs changes, or it's just incomplete.
It's not often that the interface is wrong,
most of the time it's just incomplete,
and there's, like, you find out as some important thing
is missing for you to be able to use it effectively.
And then we have to figure out how to either fix the interface
or just complete it.
This is pretty generic.
Like what it actually ends up looking like in practice,
is that, Lana, this is one merging all these public APIs.
I'm the one trying to use them.
I find out it doesn't work, and I have to complete them.
Not amazing.
So how do we make Lana talk with system D,
or in other words, how do we make Lana
to his own consumer of his own stuff?
It seems that the duration is fine.
It seems that the situation is fine.
Yeah.
So all we need to do is, of course,
it's great, it's system D's own distribution rights.
Like we reject the Unix philosophy,
right, we've stolen DNS, we've stolen network,
we've stolen in it, we still have everything,
so why not steal the distribution as well?
That was a choke.
So what would you do for Roly?
Yeah, this slide is the one I expect to come on for our Unix,
but we'll see, we can't reinvent the entire real one we do this,
why it's just me, I don't have time to repackage the world.
So we need to reinvent the real a little bit,
but not completely, otherwise it will never get done.
It needs to be known because Lana doesn't know him, person.
So if it doesn't have no one, we'll never get Lana to use it.
It has to use as many system D tools as possible,
because if we're not using system D tools to build it,
then we're not getting the dog feeding in the first place.
The more system D tools we use,
the more we exercise the interfaces and the implementation,
the more bugs we find, which I hopefully
fixed before it gets into the hands of users,
instead of after it gets into the hands of users.
Using all the system D tools is in itself not enough,
because if we package this with a system D,
or if they use a system D stable release in this distribution,
or at least in the version of it that Lana will run,
it's too late, right?
The public APIs we've been merged already,
backwards compatibility, and we can fix them.
So it has to run system D from straight from get main,
so that we can immediately start using the new public APIs in the distribution,
exercise them, make sure they work,
fix them if they don't work, before we're tied
by backwards compatibility.
And we have to enable easy acting on system D and the distribution itself,
because we run Lana to run this,
Lana needs to be able to hang on system D,
so this needs to make that possible.
We also run Lana ideally, not to just work on system D,
but also implement all the stuff he adds to system D in the distribution,
so that we have the end-to-end thing completed,
and he gets to immediately consume the API C adds,
instead of waiting for any distribution to eventually hopefully picked out.
And as to because the MIs will,
I don't pretend to know what Lana needs on his laptop,
so, right?
Yeah, I mean system D needs to be on there,
but I don't know what packages he needs or whatever,
so I'm not going to pretend I get no,
so it's just needs to be customizable,
so that if anything's missing, Lana can just add it himself,
because much, whatever it wants, so that he's happy with the system.
And of course, while Lana does it,
extremely afraid of evil mates, he says,
so we need to do secure a measure, put it to make sure that he can sleep soundly at night.
So then we get to particle of us,
which is basically the implementation of all this requirements.
It's an immutable image-based distribution,
like, again, all the stuff, Lana wants really.
It's a mutable in the way that slice user is immutable,
at sea, and the root partition is the encrypted, of course,
but writable, and then slice user is redownly,
the invariant way Lana has described it in countless of talks.
It's very using make-away size,
so it's a system D tool, it uses a bunch of other system D tools,
so we use it, because we know it, and it forces us to do extra dark fooding.
There's an odd version, because I like arch, there's a fedora version,
because fedora likes fedora, we have GD and no,
again, Lana likes no, I like GD, so there's still a lot of verdens.
And then it's self-signed, so this is where it starts to differ a bit
from the regular or immutable distributions.
The other immutable distributions are very much focused on being
something that is built somewhere on the built machine in the cloud,
or like on a server somewhere, and then you download it,
with, I don't know if any double this version already completely does this,
actually, but the idea is that you get the key from the fan there, the signing key,
you enroll that into your UEFI firmware, or you give you small quinnets, like with the whole shimting,
which is not great, but the problem with that is that you can control what goes into the image that
way, because it's all signed by the distribution, with this, with this, we do self-signing,
so that you sign it, which means you control what goes in it, so you get full control,
like you customize the image, however you want, you sign it yourself, and your computer will only run
the stuff that you signed, and not whatever the distribution sign, so you get back some,
I think you get back control, I don't think when we, like the whole world seems to be moving towards
a mutable distributions, but I don't think we want to end up in a place where we're all using
distribution keys, in our own rolling distribution keys, I think we always want to make it possible
for users to sign things themselves, so that they retain full control, if they want to do so.
I don't think the vendor provided key is bad, I just need to think we need to make sure that
the other way is also always possible, otherwise you can end up in like awkward and not great situations.
And so, like I said, you build it yourself, so you don't download the image,
when there's an update, you build the update yourself on the system, and then install it, reboot,
and you get into the new version. That's where we're developing this stuff, so it's basically
I, it's a rapper with a giant make-or-cycle configuration that sets all of this up and with a
documentation on how to install it. So let's take a look at some workflows to make
concrete how you would start running this stuff, while installing make-or-cycle simplest,
clone the rapper, put it in your path, and you can use it. Free deployment, so you have an existing
laptop, you want to build the image to install on any device, right, a desktop laptop or whatever,
clone particle OS, edit make-or-cycle local accounts, that's where you can put all the
customizations. So any make-or-cycle setting, you can just configure where you add packages,
you add files, you switch the files system, whatever you can think of, you can do it,
build the image, then you end up with DDI with three partitions, so the ESP is there with the
signed UKEI in it. You have the variety partition for slash user, and you have the actual slash
user partition itself with your image in it. No vote partition or anything that's created on first
put, and locked against the TPM the way, I don't like once it, and then we have like a burn command
to just like it's basically, it's a DDI but a little smart, and then you get it on it to your USB,
be a variety of translation. Actually installing it the first thing you do is you set a UKEI
password. If you don't, the entire thing is pretty much useless because like an attacker will just
go into the BIOS disable secure boot and what's the point, so you need a UKEI bypass.
You need to put secure boot and set up mode, set up mode is basically, right, gets rid of the
existing keys and puts the secure boot and a state where new keys can be enrolled. Once you do that,
you boot from the USB. There will be a, you'll get it to a system reboot. There will be a
very nice and roll secure boot keys menu entry. You select that and system reboot will automatically,
well, not automatically. The other one will roll the secure boot keys for you into the system.
Again, do this automatically, but there's a lot of horrible UKEI firmware out there, so we don't
do this by default, right? We make it a explicit choice. It will tell you that this might break
your system, in this case it won't, but it's got to be safe. And then you have secure boot setup.
That means you can select the install of UKEI for the next and it'll load. The installer mode is basically
meant for USB, like it's not, so the image is on a USB, but it's not to find all destination where you
want to install it. So you boot into the installer UKEI profile, which means that wood partition
and all that stuff doesn't get created. You just get into a shell where you can actually install
it to the disk you want it to. So it'll auto lock you in this route and you can just run
system de-report after that to actually deploy the image to the disk that you want it to own.
That is what, because that arrays is your drive, right? We don't do tool boot yet,
they're installing to existing systems, so currently you have to erase whatever is on that disk
to be able to install this. And then you reboot, and then this is what your
disk will look like. So we have those first three partitions that are, of where in the image,
those just got copied to the target disk and then we created the whole bunch of new partitions.
A very partition, and another use partition. So those are the B partitions, right? This is an
AB setup. You install to the B partition, the update, and I use switch to it.
So our partition I created, I created it against the TPM boot partition, I created it against the TPM,
and the separate home partition to be used with not encrypted, but to be set up to be used with
the system de-home. First boot, I mean pretty simple, you select the regular UKI profile,
system de-first boot runs, asks you a bunch of questions, a couple first boot runs, and sets up your home
for your regular user, you log in, you change your bunch of home de-settings, because the defaults
will horribly break, and absolutely not work at all. I got locked out of my home five times trying
to get this to work, so there's some bucks to face there. But for now, we change all bunch of
settings, and then it does work, and then you enable your display manager of choice. So as
the DM for KDE or KDM for a dome, and then it's installed, right? Then you log in and you get into
your desktop environment, and you can set up the thing the way you like it. How to hack on system de,
so the base image is immutable, so no compiler, no mess on or whatever in there, right? The
bigoted base image gets a longer update stake, so you don't want to make it too big. So what
other immutable distributions do is like this for a box or containers, whatever, to do all the
development. That means OCI, if you say OCI, Leonard runs away, so that doesn't work, so I
implement something and make our site to basically do the same thing, right? It's a sandbox where
you can install all the development tools you need. So it does it automatically, so if you
do run that in the system de-repo, it'll just download all the stuff you need, and you can run it from
there. And then, right, you do development with make our sciences, and the S usual, right? You
spawn of EM, and then you can test changes. And then the final one is update, so you added that
make us add a local confer file again, add by the practice one, build the update, and then you
run make our sciences update updates, which will install to the B partitions, right? We are empty
on the first update, and then the old version on when you do it the next time. It will copy the
UGI to the ESP, and that's it, that's the update, so it should be very atomic. And of course,
there's a B partitions, so if the new update doesn't work, you can always go back to the old version,
and report a book, or I don't know. Then, yeah, so reboot to get into the update. So this is
like important, it's not like the NF upgrade, where you're just upgrade, and then continue using it,
each update requires a reboot. So what I've noticed is that I update last, because of that means
me's a reboot. Like, I don't know, we probably need to do something about this,
eventually, but because having to reboot for each update is kind of annoying, but it works,
you just end up updating less than usual. So what do we end up with on this laptop? Of course,
because it would be extremely hypocritical to be able to hack a laner about not using all of this stuff,
and then do this presentation from a laptop that's not using all of this stuff either, so this is
running quite a close. It has been for a few months, and we end up using all of these things.
So, no piece of unlock that yet, because I have no clue how to set it up.
Laner needs to tell me, then we can probably enable piece of unlock as well, or at least I hope,
and then we don't use all the extensions stuff yet either, because you built the image locally,
and you are full control over it, so there's no real point in the extensions.
So, like, we still need to figure something out for that. Does it work? Yeah, I find
for questions in system, the I report them, and they get fixed, so that's great.
Not really, there's also a lot of questions that are stuff that doesn't work that doesn't get fixed,
so it's whatever, but I have found regressions, and they were fixed, so it is helping that way.
Call to action for Laner, right? Let's focus on building end-to-end solutions. Don't just
merge the API in system, they also get it running a particle of S, so that we're actually using it.
Let's make sure we can super-own API immediately. Edo ourselves, or I use it, and
switch to particle OS. What's missing? Look, guys, working on building these images in a build system,
still needs a lot of work, but then you could actually download the update instead of building it yourself.
That's the part that's going to for stock, putting of all the extensions stuff, because then it's
signed by a vendor key, you can modify it locally immediately anymore, so that will help us get
talk, putting for that part, might be Sherlock, I mentioned, add more distributions, we have
auction for Dora, but of course I want to add more if, like I'm sure some people would love
to have the inversion, desktop environments eventually do a boot and get Laner to use this.
Basically, the stock is this, that was the end. Happy to answer any questions.
Yeah.
This is probably a question for Laner more than me.
I mean, you can do that, but I think ultimately the wallets should probably be unlocked by
some key that's derived from the directory, and I've been talking to a few people about this,
like what they wanted to do with that. They're in ideas, but it's more of a leap,
you haven't even talked earlier than this, where it was talking about user credentials,
credentials, this isn't potential, that's kind of what they want to use there.
Is there any free codes, boots, any integration, so that, like, it affects the system,
like, a system failed, and then it refers back to the old thing.
So there is a target? Yeah, so is there any, like, I guess, automatic rollback is what you're,
yeah, so I know there is a target for this and system the first, which one, what's the name again?
Yeah, blast boot, that's so on, yeah. So you can order stuff before that, and then if it fails,
it'll do the rollback, and we have boot counting, like, set up. In part of the grass, but I don't,
we don't order anything before blast boot again, already, so I don't know if we have any stuff,
already, that is order before that, that will roll back if it fails. So it's there, but it's
probably pretty basic and could be extended a lot more, but you can always do it manually, of course.
Yes, so that's part of the look as work, oh yeah, so the question was, the first one is if you have an
infected, a mutable system, then if you build the update on the system itself, it'll, I mean, it'll
also be, or there's a good chance that it'll also be infected. So how do we get rid of that?
I'll answer that first and I'll get to the second part. So I think the idea, the idea there is that we
have factory reset, so if you have an infected system, then in this case you would have to do a
complete factory reset to get rid of all state, but keep the, you can keep the, all the
measured or all the trusted stuff like your slash user, but all the rest goes away and then you start
from scratch. And then the second question was, does it also make sense to get a default version
that is provided by the distribution of the, or an image that's provided by the distribution,
and so the answer is yes, and that's basically the part that look as working on, it's not trivial
for existing build systems to actually be able to do this signing. So we're trying to get this
working in the open-suced build system, which is offline signing, so you can sign when you're doing the
image build. It's a completely separate async process. So the entire build process has to be modified
to extract all the data that needs to be signed, without actually signing it, then get it signed
by completely different thing, get those inputs back, and then insert them into the, into the image.
This is a very different workflow than what you usually do, which is just, you sign when you need
to end the build process itself. So we need to do quite a few horrible changes, yeah, he is doing
all the hacks required to make that work, but we'll get to our eventually, I think.
So the use case is when you have the vendor signed image. Oh, yeah, that's a lot of
the use case is when you have the vendor signed image. Oh, yeah, that's a, well, how do
it says X fit into the, to the picture presented here was a question. So it says X are for like when you build,
like I said with OBS, if you build it on OBS, then the key, then you have a vendor signed key,
or vendor provided key, so then you can modify it all locally. So then you're kind of forced to use the
extensions, because you can sign those locally with your own key, which then has to be enrolled
with markers something like that, and then that's where those things become required. What is,
that's for if you want to build your own additions locally, but what's also possible, of course,
is that the distribution itself provides a pre-built set of CISX, which are much more course,
STEM packages. So there would be a lot more in each CISX, you would have a lot fewer of them,
but you could then install instead of installing a package, you would install a CISX for the specific
functionality, you need it, and that allows you to keep the base image small, because you don't
have to put everything in it, but then you can apply specific CISX to get the functionality that
you need as a user. So it's kind of similar, but it would, it would never be as fine grain as packages,
you're never going to have like thousands of bag out of CISX, you would have the idea to have
much for you. I think that's all, and we have so all this time.