Boots and Breakups
Mar 29, 2026
Ubuntu wants a leaner, stricter GRUB, and your favorite setup may not survive the cut. We break down what’s really changing, and the practical ways to adapt. Plus, Chris moves on from one of his favorite open source apps.
Sponsored By:
- Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!
- Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.
Links:
- 💥 Gets Sats Quick and Easy with Strike
- 📻 LINUX Unplugged on Fountain.FM
- LinuxFest Northwest 2026 - Back to Root — April 24-26, 2026 - Bellingham, Washington
- This Week In Bitcoin 97 | Jupiter Broadcasting
- Ubuntu 26.10 Looks To Strip Its GRUB Bootloader To The Bare Minimum For Better Security
- Streamlining secure boot for 26.10 - Ubuntu Community Hub
- Mitigating BootHole – CVE-2020-10713 and related vulnerabilities | Ubuntu
- There's a Hole in the Boot - Eclypsium
- Final Release · ErsatzTV — It is time for me to announce the final release of ErsatzTV in its current form. The existing repositories will be archived following this update.
- ErsatzTV/next
- Tunarr · GitHub — Create a classic TV experience using your own media — IPTV backed by Plex, Jellyfin, Emby, or NFO.
- Threadfin
- xTeVe
- Filler - Tunarr — Filler lists are collections of content used by Flex to pad time between episodes. One reason to use filler is to simulate traditional television by playing advertisements between episode airings.
- Dispatcharr — Dispatcharr (pronounced like "dispatcher") is an open-source powerhouse for managing IPTV streams, EPG data, and VOD content with elegance and control.
- awesome-iptv — A curated list of resources related to IPTV
- Tunarr API Reference
- LINUX Unplugged 645 — We cut the streaming cord the Linux way with free, legal internet TV you can curate, DVR, and self-host via Jellyfin or Plex.
- turnstonelabs/turnstone — Experimental multi-node AI orchestration platform. Deploy tool-using AI agents across a cluster of servers, driven by message queues or interactive interfaces.
- Open-Source "GreenBoost" Driver Aims To Augment NVIDIA GPUs vRAM With System RAM & NVMe To Handle Larger LLMs
- GeneBean's Cage Kiosk
- GeneBean's Pi Arm Build Setup
- Planify - Task Manager for GNU/Linux
- alainm23/planify: Task manager with Todoist, Nextcloud & CalDAV support designed for GNOME
- Pick: bore — bore is a simple CLI tool for making tunnels to localhost
- nixos-bore-module — Self-hosted bore tunnel server for NixOS
- Pick: kdeconnect-sms-tui — Terminal UI for sending and receiving SMS/MMS via KDE Connect.
- Pick: Busybridge — Complex calendar free/busy syncing across organizations for consultants who work inside multiple orgs.
Transcript
WEBVTT
00:00:11.375 --> 00:00:16.235
Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris.
00:00:16.395 --> 00:00:17.075
My name is Wes.
00:00:17.295 --> 00:00:18.215
And my name is Brent.
00:00:18.595 --> 00:00:22.535
Hello, gentlemen. Coming up on the show today, it's our take on Ubuntu's plan
00:00:22.535 --> 00:00:26.175
for a leaner, meaner grub that drops some of our favorite features.
00:00:26.455 --> 00:00:31.715
And then one of my favorite open source apps of all time is coming to an end.
00:00:32.295 --> 00:00:35.315
And what I'm going to do, my alternative, and what I'm switching to,
00:00:35.395 --> 00:00:36.115
tell you about that today.
00:00:36.435 --> 00:00:39.175
Then we'll round the show out with some great boosts, some picks,
00:00:39.375 --> 00:00:42.435
and a lot more. So before we get there, let's say time-appropriate greetings
00:00:42.435 --> 00:00:44.555
to our virtual lug. Hello, Mumble Room.
00:00:44.815 --> 00:00:47.595
Hey, Chris. Hey, Russ. And hello, Brent. Hello.
00:00:47.715 --> 00:00:47.895
Hello.
00:00:48.515 --> 00:00:51.895
Hello up there in the quiet listening. Always like having the Mumble Room.
00:00:51.915 --> 00:00:54.995
Here's our virtual lug every single Sunday. We get started with them...
00:00:55.806 --> 00:00:59.786
Quite a while before the show and hang out and talk and stuff like that.
00:01:00.006 --> 00:01:04.046
And you're always welcome. Jupyter Broadcasting dot com slash mumble for details on that.
00:01:04.366 --> 00:01:08.906
And say good morning to our friends at defined dot net slash unplugged.
00:01:08.966 --> 00:01:09.986
Go meet Define Networking.
00:01:10.226 --> 00:01:14.226
They have managed Nebula. And when you go to defined dot net slash unplugged,
00:01:14.246 --> 00:01:18.246
you'll get started with up to one handy host for free. No credit card required.
00:01:18.526 --> 00:01:23.146
And you can check out what we think is one of the absolute best mesh network
00:01:23.146 --> 00:01:27.246
in the world. We love the Nebula platform, and that's what Managed Nebula is
00:01:27.246 --> 00:01:28.226
from Defined Networking.
00:01:28.546 --> 00:01:33.546
It's a really strong contender. You can control the flexibility and discoverability
00:01:33.546 --> 00:01:38.206
of the network and the redundancy of the network, and their long-term story really shines.
00:01:38.726 --> 00:01:44.846
It's a much more, let's just say, reliable long-term story, especially when
00:01:44.846 --> 00:01:48.886
it comes to the 100 hosts for free, and they give you real control.
00:01:49.506 --> 00:01:54.486
And one of the things I love is I have found it to be surprisingly good just
00:01:54.486 --> 00:01:57.546
for a couple of machines that are doing direct-to-direct backup that I don't
00:01:57.546 --> 00:02:02.126
need a big tech login for. I don't need a key that expires every whatever days
00:02:02.126 --> 00:02:03.186
or any of that kind of stuff.
00:02:03.326 --> 00:02:05.066
I just need two machines to talk
00:02:05.066 --> 00:02:08.826
reliably to each other, and the entire infrastructure is between them.
00:02:09.146 --> 00:02:13.046
But then, of course, this was designed to manage Slack's global infrastructure
00:02:13.046 --> 00:02:18.006
back in 2017. So it hit the ground running for one of the most important data-sensitive
00:02:18.006 --> 00:02:22.106
companies in the world with one of the largest distributed backends in the world.
00:02:22.626 --> 00:02:27.506
Nebula is really incredible. And what's amazing is it's so light on the CPU
00:02:27.506 --> 00:02:28.746
and the networking, too.
00:02:28.886 --> 00:02:33.166
And they just recently introduced Always-On VPN mode for iOS and Android.
00:02:33.346 --> 00:02:38.546
So now your mobile devices can participate in what is the best mesh networking out there.
00:02:38.826 --> 00:02:43.146
So go check it out. Support the show. and free for 100 hosts.
00:02:43.406 --> 00:02:48.126
Define.net slash unplugged. That's Define.net slash unplugged.
00:02:48.226 --> 00:02:51.746
Go redefine your VPN experience today. Check out Nebula. See why we love it.
00:02:51.846 --> 00:02:56.686
See why we have been thrilled to have them as a sponsor and why we're deploying it on our systems.
00:02:59.755 --> 00:03:04.295
A quick mention, if you'd like to catch a very unplugged version of This Week
00:03:04.295 --> 00:03:10.775
in Bitcoin, This Week in Bitcoin episode 97 is an agent-friendly node management for 2026,
00:03:11.095 --> 00:03:14.835
where Brent and Wes both sat down with me for a special episode.
00:03:15.395 --> 00:03:18.115
So that's ThisWeekinBitcoin.show, and it's episode 97.
00:03:18.655 --> 00:03:20.155
I still have more node work to do.
00:03:20.255 --> 00:03:20.535
We do.
00:03:20.655 --> 00:03:21.375
That was a lot of fun, though.
00:03:21.815 --> 00:03:24.755
And then, just a reminder, LinuxFest Northwest, just around the corner,
00:03:24.935 --> 00:03:28.055
and we will have a live show. We'd love to see you there. We don't quite have
00:03:28.055 --> 00:03:29.255
all the details ironed out.
00:03:29.755 --> 00:03:34.355
But plans are already in the works, and I think it's going to be a really great event.
00:03:34.795 --> 00:03:39.835
And I'm really hoping we get the classic late April spring where it's just beautiful.
00:03:40.135 --> 00:03:42.915
Maybe you never know. Maybe if we did, maybe we'd do the episode outside.
00:03:43.095 --> 00:03:43.975
That could be a lot of fun.
00:03:44.635 --> 00:03:47.255
And we may have a hookup on speakers this year, too. I mean,
00:03:47.295 --> 00:03:50.575
not like people that speak, but speakers that we can put in the crowd so people
00:03:50.575 --> 00:03:53.955
can hear the show really well. How about that for getting fancy?
00:03:54.335 --> 00:03:55.235
Speakers for the speakers?
00:03:55.275 --> 00:03:59.535
I like that idea. We just need to prepare ourselves to implement it.
00:03:59.755 --> 00:04:00.995
Yeah, that's true. That's true.
00:04:04.335 --> 00:04:08.895
Big news this week. Canonical has announced big changes.
00:04:09.315 --> 00:04:13.335
Well, maybe you could call them minimal changes to Ubuntu 26.10's grub.
00:04:13.475 --> 00:04:16.595
They're calling it a minimal grub for secure boot.
00:04:16.855 --> 00:04:22.915
Their idea is to reduce the attack surface for grub and remove certain features
00:04:22.915 --> 00:04:24.455
that could be exploited.
00:04:24.995 --> 00:04:28.515
Some of those features are some of our favorite features.
00:04:28.755 --> 00:04:31.895
So, Wes, walk us through kind of the high level of this and then maybe we can
00:04:31.895 --> 00:04:33.575
get into what's getting removed.
00:04:33.575 --> 00:04:38.215
Yeah, well, we can talk about just sort of some of the stuff from the post itself.
00:04:38.395 --> 00:04:38.515
Yeah.
00:04:39.335 --> 00:04:43.975
Ubuntu Systems supports Secure Boot using Grub. And if you remember from,
00:04:44.675 --> 00:04:47.075
well, really the last, what, 10, 15 years?
00:04:47.315 --> 00:04:47.475
Yeah.
00:04:47.875 --> 00:04:53.615
Secure Boot is a new standard that came along with sort of our switch to UEFI booting of systems.
00:04:54.015 --> 00:04:58.675
And it provides ways to have the firmware have a set of cryptographic keys that
00:04:58.675 --> 00:05:02.935
it trusts and then verify that it's only going to boot into operating systems
00:05:02.935 --> 00:05:04.035
signed with those things.
00:05:04.355 --> 00:05:07.875
And on its own, as just that, as a primitive, like, that's one thing.
00:05:08.015 --> 00:05:11.275
It can be used for whatever, right? It's like a new tool that your computer can do.
00:05:11.555 --> 00:05:15.355
It can be very useful if you want to operate in a secure way and you want confidence that, like,
00:05:15.933 --> 00:05:19.133
Your machines only ever run code that you signed and no one else can,
00:05:19.253 --> 00:05:20.733
even if they have the hardware, can run stuff on it.
00:05:20.893 --> 00:05:24.193
So it's always made sense, like in the context of an important business laptop
00:05:24.193 --> 00:05:28.773
where you're out and about and you want to make sure your laptop hasn't been, you know, messed with.
00:05:28.973 --> 00:05:32.173
Or obviously in a data center where other people have access, things like that.
00:05:32.293 --> 00:05:35.893
And physical security is really important in these things because if somebody
00:05:35.893 --> 00:05:38.173
gets physical access, then they can essentially get root to the box.
00:05:38.233 --> 00:05:41.433
So you just want to verify that that chain is as secure as possible.
00:05:41.573 --> 00:05:42.873
I get that use case. All right.
00:05:43.033 --> 00:05:46.813
But of course, in the real world, what actually happened is also that Microsoft
00:05:46.813 --> 00:05:51.153
ended up being behind a lot of this and they wanted to push it out to like consumer laptops as well.
00:05:51.633 --> 00:05:53.613
And so you need some kind of key if you're going to do that,
00:05:53.673 --> 00:05:56.373
right? And you're going to want to run Windows and it's not an open source.
00:05:56.453 --> 00:05:57.873
Somebody has to sign it. Only Microsoft does that.
00:05:57.993 --> 00:05:58.073
Right?
00:05:58.333 --> 00:05:59.693
Yeah, Microsoft signs the key.
00:05:59.833 --> 00:06:02.353
And then it just worked out that it's not that you, in most situations,
00:06:02.453 --> 00:06:05.913
not all, in most situations, you can set up and enroll your own keys and sort
00:06:05.913 --> 00:06:07.213
of manage it as you would hope.
00:06:07.333 --> 00:06:09.633
That's not true for every single device, especially like Windows on ARM for
00:06:09.633 --> 00:06:10.733
a while, like all kinds of things.
00:06:10.733 --> 00:06:13.473
but it also means we live in a world where
00:06:13.473 --> 00:06:16.293
like if you want to just be able to have secure boot and boot
00:06:16.293 --> 00:06:19.073
a random iso on a random laptop you probably need it signed
00:06:19.073 --> 00:06:21.773
by that key and we have like a sort
00:06:21.773 --> 00:06:25.233
of complicated setup depending on the distro around like microsoft
00:06:25.233 --> 00:06:29.473
signs a tool called shim which then has its own set of signatures for various
00:06:29.473 --> 00:06:33.353
distros that then it has keys baked into that it trusts when it gets signed
00:06:33.353 --> 00:06:36.893
for like okay i can boot these ubuntu things right and then that's where like
00:06:36.893 --> 00:06:41.533
Ubuntu's system of assigned Grub2 comes in. And so that's where it's important
00:06:41.533 --> 00:06:42.633
to understand sort of the history.
00:06:42.773 --> 00:06:45.713
Like back in 2020, there was a vulnerability called boot hole.
00:06:45.953 --> 00:06:51.233
And this was actually a flaw where Grub had in parsing its own config that led to vulnerability.
00:06:51.833 --> 00:06:54.053
But the important part is like it just...
00:06:54.920 --> 00:06:59.540
It's a lot to deal with when that happens because you now need to go basically
00:06:59.540 --> 00:07:04.480
figure out how to like, you know, there's going to be old shims that trust vulnerable
00:07:04.480 --> 00:07:07.800
versions of Grub, but that are still trusted by the firmware.
00:07:08.040 --> 00:07:10.900
So if you want to do it properly, you have to get a new version of Grub that
00:07:10.900 --> 00:07:11.920
doesn't have the problem.
00:07:12.220 --> 00:07:16.260
Test that, make sure it's going to work everywhere, and then sign that,
00:07:16.420 --> 00:07:20.640
but with updated keys that aren't going to be trusted for the old ones,
00:07:20.720 --> 00:07:23.880
and then roll that up in the shim layer, and then coordinate with Microsoft
00:07:23.880 --> 00:07:26.380
to get the new version of the shim thing signed potentially.
00:07:26.680 --> 00:07:30.660
And then maybe even you need to go like add to the blacklist on the actual hardware
00:07:30.660 --> 00:07:33.420
things to say, you know, so it knows keys that it shouldn't trust anymore.
00:07:33.640 --> 00:07:35.600
And then you've got to get that pushed out to end users.
00:07:35.760 --> 00:07:35.880
Yeah.
00:07:36.080 --> 00:07:38.860
And they've got to do a successful update that's updating their bootloader.
00:07:38.960 --> 00:07:42.000
And then if you don't, then it just means sort of means like any old ISOs floating
00:07:42.000 --> 00:07:44.140
around are vulnerable and could have problems.
00:07:45.040 --> 00:07:47.520
And then there's potential attacks. I don't think this is the main concern necessarily,
00:07:47.640 --> 00:07:51.160
but like there are in theory some potential attacks where you could boot a Linux
00:07:51.160 --> 00:07:54.460
setup from like a vulnerable thing that let you then circumvent secure boot
00:07:54.460 --> 00:07:57.100
and use that to attack windows systems on the same laptop,
00:07:58.100 --> 00:08:01.960
so there's just a lot of sort of ecosystem implications that have happened in
00:08:01.960 --> 00:08:05.440
the past that i think they don't specifically mention that but i think there's
00:08:05.440 --> 00:08:07.120
a lot of that sort of history,
00:08:07.760 --> 00:08:11.860
behind this change so basically a bunch of supports grub for secure boot they
00:08:11.860 --> 00:08:17.340
use grub to boot things in 2610 they're proposing to remove the following features
00:08:17.340 --> 00:08:18.660
and if you've ever used grub you know that,
00:08:19.750 --> 00:08:24.010
It's existed long before the modern era of ESPs and UEFI and all that.
00:08:24.070 --> 00:08:25.350
So it supports a ton of different stuff.
00:08:25.490 --> 00:08:30.210
So they want to remove support for file systems for the slash boot drive.
00:08:30.390 --> 00:08:32.330
And actually, maybe it's worth talking about here too.
00:08:33.250 --> 00:08:37.510
Some Linux setups, they just have slash boot as like the ESP, the system partition.
00:08:37.910 --> 00:08:43.490
The EFI standard mandates like this VAT32 partition. And that's what the firmware interacts with.
00:08:43.870 --> 00:08:47.290
Linux often has its own sort of boot setup. And then so you have some setups
00:08:47.290 --> 00:08:51.150
that where you have the EFI system partition often mounted at slash boot EFI,
00:08:51.410 --> 00:08:55.270
but then you also have like a Linux boot partition that could be a different
00:08:55.270 --> 00:08:56.890
file system mounted at slash boot.
00:08:57.010 --> 00:09:00.330
And so you might have just the bare EFI stuff on the EFI partition,
00:09:00.330 --> 00:09:03.210
and then a lot more of the actual Linux boot stuff lives on the Linux side.
00:09:03.370 --> 00:09:09.690
That's how I do it. Is that how you do it? Well, I think boot EFI is its own thing if I'm using Grub.
00:09:09.850 --> 00:09:13.230
I almost use Grub almost on everything, except for like one system.
00:09:13.430 --> 00:09:15.290
See, I think I mostly use systemd boot.
00:09:15.290 --> 00:09:18.730
Brent, do you put it all under slash boot or do you break off boot slash EFI?
00:09:20.150 --> 00:09:24.830
Yes. I have so many systems that have like gone through our phases of,
00:09:25.010 --> 00:09:30.290
so these days it's like mostly systemd boot, but it's a little all over because I got systems all over.
00:09:30.510 --> 00:09:33.810
The reason I ask is because what I do, and I think this is going to impact me,
00:09:34.090 --> 00:09:36.270
is so slash boot EFI is FAT32.
00:09:37.315 --> 00:09:39.975
But Slash Boot, it's usually ButterFS.
00:09:40.235 --> 00:09:42.695
Right. And, you know, there's trade-offs like...
00:09:42.695 --> 00:09:44.795
And they're dropping ButterFS with this change. Like, we haven't gotten to that
00:09:44.795 --> 00:09:49.255
part. So I guess I interrupted you, but I just wanted to ask you that.
00:09:49.435 --> 00:09:53.335
So the changes here is happening at Slash Boot, but some people still have Slash
00:09:53.335 --> 00:09:54.795
Boot EFI, and there's that nuance there.
00:09:54.835 --> 00:09:56.555
Well, yeah, and you have to have the EFI partition.
00:09:56.735 --> 00:09:56.875
Yeah.
00:09:56.955 --> 00:09:58.195
The question is, do you, like...
00:09:58.195 --> 00:09:59.635
Make the whole thing FAT32 or...
00:09:59.635 --> 00:10:02.655
Right, and do you want to have stuff that exists on a separate Slash Boot?
00:10:02.795 --> 00:10:05.455
And, you know, there's a variety of different setups, and there's trade-offs,
00:10:05.555 --> 00:10:08.235
and, like, some ESPs are only so big, so you can only have so many generations
00:10:08.235 --> 00:10:12.075
of kernel and RAMFS, and there's a lot of variation here because Linux, right?
00:10:12.375 --> 00:10:16.135
So what they're proposing here in light of this because Grub supports a lot
00:10:16.135 --> 00:10:20.515
of stuff is for slash boot, they want to and basically this means removing it
00:10:20.515 --> 00:10:25.875
from signed Grub builds, and that's important here removing from signed Grub builds Okay.
00:10:25.875 --> 00:10:27.795
So on regular unsigned Grub builds?
00:10:28.575 --> 00:10:31.595
Yeah, you would still have access to these features Oh, okay,
00:10:32.175 --> 00:10:36.235
But remove ButterFS, HFS+, xfs
00:10:36.235 --> 00:10:40.135
and zfs retain ext4
00:10:40.135 --> 00:10:43.815
fat iso 9660 and squash
00:10:43.815 --> 00:10:46.895
fs also remove support for jpeg
00:10:46.895 --> 00:10:49.795
and png retain no support for images at
00:10:49.795 --> 00:10:54.995
all and then remove stuff for like i guess just remove support for apple partition
00:10:54.995 --> 00:10:58.295
tables which okay that seems reasonable i suppose in addition to these simpler
00:10:58.295 --> 00:11:01.755
changes we're also going to remove support for slash boot on complex partition
00:11:01.755 --> 00:11:07.475
setups such as lvm md raid except RAID 1 and Lux encrypted slash boot.
00:11:07.735 --> 00:11:11.655
These abilities were inherited by Debian but never tested in Ubuntu,
00:11:11.835 --> 00:11:15.355
and the Ubuntu installer always set up a bare ext4 partition.
00:11:15.715 --> 00:11:19.075
And then they sort of go into some of their reasoning here. As for encryption
00:11:19.075 --> 00:11:22.995
in particular, encryption of slash boot only provided security by obscurity,
00:11:23.235 --> 00:11:24.475
but not actual security.
00:11:24.695 --> 00:11:27.335
You want to ensure the integrity of those pieces.
00:11:27.695 --> 00:11:31.735
Our TPM FTE solution correctly implements integrity in the early boot stage,
00:11:31.735 --> 00:11:35.475
and we are committed to keep iterating and improve on it.
00:11:36.181 --> 00:11:39.321
Keep in mind these changes only affect slash boot. The file system,
00:11:39.421 --> 00:11:42.761
partition tables, Lux, LVM, RAID solutions continue working in the booted system.
00:11:42.901 --> 00:11:45.061
We are not removing them from the Linux kernel.
00:11:45.421 --> 00:11:48.761
Thank you, Wes. That was a really good breakdown. I think the biggest thing
00:11:48.761 --> 00:11:51.421
that's probably shocking here is the removal of Lux.
00:11:51.681 --> 00:11:56.561
I think most people can kind of understand reducing the file system scope,
00:11:56.601 --> 00:11:58.341
although I am sad to see Butter or Fesco.
00:11:58.501 --> 00:12:01.461
In particular, I think it's probably the least of the concerns here.
00:12:01.461 --> 00:12:05.821
And I think also distributions downstream are going to be really disappointed
00:12:05.821 --> 00:12:07.321
in the lack of image support.
00:12:07.741 --> 00:12:10.641
I've already seen some distributions talking about that.
00:12:11.461 --> 00:12:16.521
I will bring up just a friend of the show, Neil Gampa, was quick to comment
00:12:16.521 --> 00:12:20.621
in here, noting, suggesting, hey, can we please not drop ButterFS?
00:12:21.561 --> 00:12:25.661
It's a read-only file system driver that is actively supported by upstream developers.
00:12:25.801 --> 00:12:30.481
Users who want to leverage boot-to-snapshot setups with ButterFS need this support.
00:12:31.081 --> 00:12:31.681
That's exactly right.
00:12:31.881 --> 00:12:35.241
So there's some nuance here too. And then ZFS users are sort of bringing stuff up.
00:12:35.361 --> 00:12:39.501
Like there's the question of, is the obligation to sort of support this around
00:12:39.501 --> 00:12:43.541
what just the Ubuntu installer did or the wider array of setups people have
00:12:43.541 --> 00:12:49.061
crafted around running even secure boot Ubuntu on different disk configurations in the wild?
00:12:49.361 --> 00:12:52.981
I wouldn't be surprised if they have to walk the Lux decision back.
00:12:53.241 --> 00:12:57.201
I grant that they are saying that encryption of slash boot only provides security
00:12:57.201 --> 00:13:02.201
by obscurity, but not actual security. There's one other thing that Encrypted
00:13:02.201 --> 00:13:06.261
Lux provides that they didn't mention in that paragraph, and that's corporate compliance.
00:13:06.681 --> 00:13:12.081
And there's not a lot of nuance in a corporate policy that requires your entire
00:13:12.081 --> 00:13:15.181
laptop hard drive be encrypted.
00:13:15.421 --> 00:13:19.321
They don't generally allow for, well, your entire laptop should be encrypted
00:13:19.321 --> 00:13:21.081
except for your boot partition.
00:13:21.681 --> 00:13:23.941
That's not generally how the corporate policies are structured.
00:13:23.941 --> 00:13:28.561
And so I wouldn't be too surprised if the feedback from enterprise customers
00:13:28.561 --> 00:13:31.841
is, sorry, chief, but we've got to have luck.
00:13:32.101 --> 00:13:35.621
Even on Windows, you have the ESP can't be encrypted.
00:13:35.941 --> 00:13:36.221
Yeah, yeah.
00:13:37.414 --> 00:13:40.534
But I would still, I think they would still argue that there's value in having
00:13:40.534 --> 00:13:42.214
like the kernel images and all. I'm not saying.
00:13:42.334 --> 00:13:42.894
Yeah, fair enough.
00:13:43.094 --> 00:13:43.434
I'm not saying.
00:13:43.554 --> 00:13:47.054
There's often compliance drag and yeah, it takes a long time to get stuff updated.
00:13:47.114 --> 00:13:50.274
I think the analysis is technically true that it's security through obscurity,
00:13:50.434 --> 00:13:54.454
especially when you have their TPM backed solution for verifying all the other
00:13:54.454 --> 00:13:55.414
aspects of the boot chain.
00:13:55.534 --> 00:13:59.774
So when you have all other things being true, it is security through obscurity.
00:13:59.954 --> 00:14:02.534
But I don't think corporations are really thinking about it that hard.
00:14:02.654 --> 00:14:05.834
Yeah, that's fair. and it has to be what their auditors are willing to and that
00:14:05.834 --> 00:14:07.614
their standards already exist and support.
00:14:07.794 --> 00:14:11.994
That's the thing. But this is something they're working out now because this
00:14:11.994 --> 00:14:13.894