Canonical's GRUB Saboteur Has a 10-Year Plan

On March 25th, 2026, a Canonical engineer named Julian Andres Klode posted a proposal to the Ubuntu Discourse titled "Streamlining secure boot for 26.10" that would strip support for btrfs, xfs, zfs, hfsplus, JPEG, PNG, LVM, and LUKS-encrypted disks from Ubuntu's signed GRUB bootloader builds. The practical consequence is that every Ubuntu system running 26.10 or later would need its `/boot` partition on a raw ext4 filesystem, unencrypted, on a GPT or MBR disk, or it simply will fail to boot with Secure Boot enabled.

This is a demolition project, it's been running for five years now.

Julian Klode is the lead developer of APT, the package manager that powers every Debian and Ubuntu system on the planet. He's been a Debian Developer since October 2008 and an Ubuntu Core Developer since July 2016. He was promoted to Senior Engineer at Canonical in November 2025, four months before dropping this proposal. He manages the entire shim/GRUB/kernel signing pipeline for Ubuntu's Secure Boot infrastructure, meaning he controls the keys that decide what your computer is allowed to run at boot time.

And in 2016, a full decade before this proposal, he built a tool called sicherboot that replaced GRUB with systemd-boot and handled Secure Boot signing automatically. "Sicher" is German for "secure." He archived it in January 2023 and recommended users switch to sbctl instead, but the intent was clear a decade ago: he wanted GRUB gone.

In December 2021, Klode disabled os-prober in GRUB 2.06, which broke automatic dual-boot detection for millions of Ubuntu users who also run Windows or other Linux distributions. His exact words on the mailing list were that the outcome was "obviously a bit controversial and not necessarily in the best interest of our users," and he did it anyway because os-prober mounts all partitions on your disk using grub-mount, which he called a security risk.

In October 2023, he proposed dropping grub-coreboot, grub-efi-ia32, grub-xen, grub-uboot, and grub-firmware-qemu from Ubuntu, claiming "we believe nobody uses them." Steve Langasek pushed back, pointing out that removal requires demonstrating actual maintenance burden. In the same email, Klode floated killing BIOS support entirely, calling it "a risky platform."

In October 2025, he announced a hard Rust dependency for APT starting May 2026, effectively threatening four Debian architectures that lacked Rust toolchain support: DEC Alpha, HP PA-RISC, Motorola 680x0, and Hitachi SH4. He closed with "thank you for understanding," which is corporate shorthand for "the discussion is over." John Paul Adrian Glaubitz called his wording "unpleasant" and "confrontational."

And now, March 2026, the biggest cut yet: remove six filesystem drivers, all image rendering, LVM, and LUKS from signed GRUB. His own words in the proposal: "We understand these are controversial options; however we believe they'd substantial [sic] improve security, but also simply pivoting to new boot solutions in the future."

Someone will point out that Fedora and other distributions are also moving toward systemd-boot. True. The difference is that Fedora offers it as an option alongside a fully functional GRUB. Klode is gutting GRUB's functionality so aggressively that switching becomes the only viable path. There's a canyon between offering an alternative and burning down the incumbent so the alternative wins by default. </div>

That last phrase is the tell. "Pivoting to new boot solutions in the future" means systemd-boot or Unified Kernel Images, and Klode has been building toward this since sicherboot in 2016. Every removal makes GRUB less functional, and eventually replacing it becomes the path of least resistance, which is exactly how you boil a frog when you also happen to control the signing keys.

And before anyone says I'm attributing malice where there's only engineering pragmatism: pragmatism doesn't require a decade of groundwork. One bad decision is a judgment call. Five decisions over five years, all moving in the same direction, all made by the same person who built the replacement tool in 2016 and controls the signing keys in 2026, that is a trajectory. I'm reading the commit history, not his mind.

Ok so the security argument has real teeth.

The NVD CVE database contains over 60 GRUB-related vulnerabilities across 2020-2025. The BootHole bug (CVE-2020-10713) was a buffer overflow in GRUB's config parser that allowed arbitrary code execution and Secure Boot bypass. Since then, GRUB's filesystem parsers have been an assembly line of heap buffer overflows: CVE-2024-56737 in HFS scored 8.8 HIGH, CVE-2025-0678 in SquashFS scored 7.8 HIGH, and the 2025 batch alone found heap overwrite bugs in seven different filesystem drivers (UFS, SquashFS, ReiserFS, JFS, RomFS, UDF, and HFS). These are all the same bug class, integer overflows leading to heap corruption, repeating in the same C codepaths year after year because GRUB's parser code was written without bounds checking.

From what I found, the filesystem attack surface is genuinely massive and continuously producing new vulnerabilities even in GRUB 2.12, the current release. Klode has a point about reducing attack surface.

But look at which modules are actually being cut and which ones are being kept. btrfs has zero CVEs. XFS has zero CVEs. ZFS has zero CVEs. All three are marked for removal. Meanwhile SquashFS, which has two CVEs including a 7.8 HIGH, gets to stay. The aggregate number of 60+ GRUB vulnerabilities sounds terrifying until you look at the actual modules on the chopping block and realize the ones users depend on have cleaner security records than the ones being retained. He's using the total to justify removing things that have no vulnerability history.

But his solution creates a bigger problem than the one it solves, and the community identified it within hours.

Removing LUKS support from GRUB means your /boot partition sits unencrypted on disk. An attacker with physical access, or malware with root privileges, can modify kernel parameters, swap initramfs images, or inject persistent bootkits without breaking any cryptographic seal. As one Discourse commenter named peb pointed out, removing encryption from the boot chain breaks the chain of trust that Secure Boot claims to protect. You harden the bootloader by making the thing it loads completely defenseless. Zero GRUB vulnerabilities appear in CISA's Known Exploited Vulnerabilities catalog, meaning every single one of those 60+ CVEs is theoretical. The attack surface exists on paper while the protection being removed, encrypted boot partitions, stops real attacks against production infrastructure right now.

User mlocik97 called it "absurd" and compared it to "improving security of planes by forbidding them to fly." DClauzel from France pointed out that encrypted `/boot` is mandatory in regulated European environments, and Klode lives in Marburg, Germany. Multiple users noted that Ubuntu 24.04 Server defaults to LVM during installation, meaning Canonical's own recommended server configuration would be incompatible with their own proposed boot requirements two releases later.

The obvious defense is that Ubuntu Server's LVM defaults and Klode's GRUB proposal come from different teams. That makes it worse. Either Canonical's internal teams have zero coordination and the left hand is stripping features the right hand depends on, or they coordinated and the server team gets overruled by the boot team anyway. Both answers are damning, and neither one helps the sysadmin whose 3 AM pager just went off.

And the migration path Klode offers is brutal: restructure your disk layout, disable Secure Boot, or stay on 26.04 LTS forever. For enterprise deployments running hundreds or thousands of Ubuntu servers with LUKS-encrypted boot partitions, "restructure your disk layout" is a euphemism for "rebuild your entire infrastructure."

Klode's own blog reveals a philosophical contradiction. His APT solver, solver3, is explicitly designed to "always keep manually installed packages around, it never offers to remove them." His 2025 post on sound removals argues that "the solution to remove A rather than upgrade it would still be wrong" when upgrading would resolve the conflict. He built a package manager that protects user choices and then built a boot infrastructure that overrides them.

And his 2021 post on migrating away from apt-key contains this gem: the "security increase is minimal, since package maintainer scripts run as root anyway." Klode treats security pragmatically when it comes to package signing, but treats the boot chain as sacred ground where user capabilities get sacrificed. The inconsistency is either dishonest or convenient, and both options lead to the same place.

This is the same Canonical that forced Snap packages on users by silently routing `apt install chromium-browser` through their proprietary store, the same Canonical that piped desktop searches to Amazon without consent and then tried to silence the critic who built a fix with trademark threats, the same Canonical whose VP of Engineering Jon Seager already distanced the company from one controversial proposal this month when a developer tried to put age verification into the Ubuntu installer.

The pattern is consistent, and it runs across multiple Canonical engineers operating in the same direction: reduce what your system can do and route the escape hatch through something Canonical controls. Dylan Taylor wanted to collect your birthday and Julian Klode wants to control which filesystems you boot from, and they both wrapped it in compliance language while generating immediate community backlash that Canonical has yet to meaningfully address.

The inevitable response is that I'm 'harassing' an open source developer for doing his job. Every single source in this article is a public mailing list post, a public Git commit, a public Discourse proposal, or Klode's own public blog. He's a Senior Engineer at a company that controls Ubuntu's boot infrastructure for millions of machines worldwide. He posted this proposal publicly and invited feedback. Public accountability for public proposals affecting public infrastructure is called journalism. If the argument against scrutiny is that the person making sweeping changes to how your computer boots deserves to do it in silence, then the argument is that you don't deserve to know what's happening to your system.

Klode's proposal remains just a proposal, and the Discourse thread is actively hostile to it. But Klode controls the signing pipeline, manages the shim and GRUB packaging and the kernel trust chain, and he has the keys, and he's been removing capabilities from GRUB for five years in a trajectory that points at exactly one destination: replacing it with the tool he built in 2016.

Phoronix covered it today. Hacker News is discussing it. The community is paying attention. Whether Canonical's leadership treats this like the os-prober incident, where the removal went through despite objections, or like the 32-bit library removal, where Valve threatening to drop Ubuntu support forced a reversal, depends entirely on whether anyone with enough market leverage cares about their boot partition.

My guess is that most Ubuntu users will find out what happened after the update breaks their server at 3 AM.