From dff36e88dd81cee8655749b275d2d22a5838aa5f Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Thu, 3 Sep 2026 17:43:34 +0000 Subject: [PATCH] Add 3.6 Secure Boot planning note under next-release/ Record what 3.6 can honestly ship without Microsoft-trusted keys: MOK, optional Debian signed-chain reuse, and the firmware-disable path already published. Confirm Phoenix/Fireproof already covers the old snapshots bet. Do not rebuild the ISO or change live-build. Co-authored-by: Bob Corbin --- next-release/3.6-secure-boot.md | 343 ++++++++++++++++++++++++++++++++ next-release/README.md | 20 +- 2 files changed, 359 insertions(+), 4 deletions(-) create mode 100644 next-release/3.6-secure-boot.md diff --git a/next-release/3.6-secure-boot.md b/next-release/3.6-secure-boot.md new file mode 100644 index 0000000..db757f9 --- /dev/null +++ b/next-release/3.6-secure-boot.md @@ -0,0 +1,343 @@ +# 3.6 planning: Secure Boot without pretending we have keys + +Status: planning only. Do not treat this file as a build brief, a package +list, or a permission to rebuild the ISO. + +3.5.0 Fire and Ice («Umbra») is already shipped. This note records what +3.6 can honestly do about known-issues item #1 — unsigned Secure Boot — +without a Microsoft-trusted Shadowfetch shim, without inventing signing +keys we do not have, and without blowing the 4 GiB ISO ceiling. + +Public source of truth today: + +- [Known issues](https://www.shadowfetchlinux.org/known-issues) — issue #1 +- [Secure Boot guide](https://www.shadowfetchlinux.org/secure-boot) +- Repo README system-requirements line, same claim + +This document does not change those pages. If a later 3.6 implementation +wants to change public wording, it needs a passing signed-boot test first. +`docs/GITHUB-CLAIM-SOURCES.md` already forbids claiming Secure Boot +support without that test. + +## What 3.5 already shipped (so we do not re-bet it) + +The May 2026 `ROADMAP-NEXT-BUILD.md` still lists **Btrfs snapshots + +boot-to-snapshot rollback** as an open signature bet and the #1 remaining +headline. That document is a post-1.0.6 backlog. It is stale. + +Verified against the 3.5.0 tree and the published 3.5.0 contract +(`RELEASE-3.5.0.md`, repo README, known-issues #3): + +| Old backlog item | 3.5.0 fact | +| --- | --- | +| Btrfs `@` / `@home` / `@snapshots` + installer path | Calamares ships. Encrypted LUKS2-on-Btrfs is a validated install path. | +| Automatic snapshots around apt | Phoenix arms snapper; Debian's `80snapper` hook wraps dpkg. Fireproof names the pre-snapshot as the rollback target and does not invent its own snapshotter. | +| Boot-to-snapshot | `grub-btrfs` is packaged and recommended by Phoenix. Recovery from a read-only snapshot session is part of the Phoenix contract. | +| “Never breaks” updates | Fireproof simulates, refuses risky removals and bad preconditions, re-verifies the change-set hash at commit, and offers rollback. It is not unattended updates and it is not Debian stable. | + +The snapshots bet is done as a product mechanism. Residual Phoenix work +in `docs/FIRE_ROADMAP.md` (ext4 “Phoenix Lite”, `@home` protection, +scheduled timelines, qgroup accounting) is polish, not the missing +differentiator. + +Secure Boot is the actual next trust-chain gap. The public site already +says so. 3.6 should treat it as the headline engineering problem, not as +a theme refresh and not as another snapshot rewrite. + +## The problem, stated without marketing + +Secure Boot is a firmware check. The keys in almost every PC's `db` are +Microsoft's. A Linux distro that boots with Secure Boot on does it by +shipping a Microsoft-signed **shim**, which then trusts the distro's own +key, which then trusts GRUB or a UKI, which then trusts the kernel. + +Shadowfetch has: + +- An OpenPGP key that signs the ISO and the APT repo + (`8F13 CE15 35EE 1F4A 2916 A1F7 3C5C 900B 7BE8 0CA1`). Firmware does + not know this key. +- No Microsoft third-party UEFI CA enrollment for a Shadowfetch shim. +- No Shadowfetch UEFI signing CA, HSM, or key ceremony in this + repository. This plan will not invent one. + +The published guide is correct: the installer USB is refused or invisible +with Secure Boot on; after install it has to stay off; re-enabling Secure +Boot stops the installed system from booting. + +Shipping `shim-signed` in the live chroot is not the same as booting +through that shim. 3.5 already lists `shim-signed` in +`live-build/config/package-lists/shadowfetch-core.list.chroot` and +`mokutil` in `shadowfetch-graphics.list.chroot`. The installed UEFI path +still runs unsigned GRUB: + +``` +grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable --no-nvram +``` + +That is `sf-install-grub`. It installs `grub-efi-amd64`, not +`grub-efi-amd64-signed`, and it does not place shim as `BOOTX64.EFI`. +The live ISO uses live-build's `LB_BOOTLOADER=grub2` plus the Umbra GRUB +theme. Those are unsigned EFI payloads. + +So: the package is on the squashfs. The trust chain the firmware sees is +still unsigned. Known-issues #1 remains true. + +## What 3.6 can honestly ship + +Three things we already have or can do without Microsoft. One thing we +must not say. Nothing below authorizes a live-build edit in this +planning change. + +### 1. Keep telling people to disable Secure Boot + +Already published. Keep it as the supported path for 3.6. + +The guide already covers the real costs: lost pre-kernel tamper check, +BitLocker recovery-key demand, Windows 11 “unsupported” noise, no kernel +lockdown (which is also why proprietary NVIDIA modules load today), and +the fact that disk encryption / TPM / APT signing do not get weaker just +because firmware Secure Boot is off. + +3.6 implementation work, if any, is **in-image honesty**, not a new +story: + +- Calamares welcome / Guide / System Passport already have a + `secure_boot` probe in tests (`disabled` / `not-available`). Surface + that on the live session when Secure Boot is on: the USB booted only + because firmware was already off, or the user is about to install a + system that will not survive re-enabling it. +- Do not add an installer checkbox that claims to “enable Secure Boot.” + Firmware is not an installer setting. The public page already says + that. +- Do not date the Microsoft signing path. The public page already + refuses to. + +This is the only 3.6 deliverable that does not need a new boot artifact. + +### 2. Machine Owner Key (MOK) — useful, not a substitute + +`mokutil` is already in the image because DKMS / NVIDIA need a way to +enroll a machine-local key **after** a shim is running. + +Honest limits: + +- MokManager is a shim feature. No running shim means no MokManager. + Enrolling a MOK therefore requires either Debian's already-signed shim + as first-stage, or the user putting firmware into Setup Mode and + editing `db` by hand. Many consumer firmwares make Setup Mode miserable. +- A MOK does not make the live USB appear in a Secure-Boot-on firmware + menu. That is still a first-stage shim problem. +- A project-wide MOK private key baked into the ISO is not a secret. + Anyone who downloads the ISO has the key. That is enrollment + convenience, not a trust root. +- A per-machine key generated at first boot is the only MOK story that + is not theater. It helps **this** machine load **this** machine's DKMS + modules after the user has enrolled it. It does not scale to “Shadowfetch + is Secure Boot signed.” +- BitLocker dual-boot still demands the recovery key if firmware + measurements change. That cost does not go away because we added a + helper. + +A 3.6-sized MOK slice, if implemented later, is a helper and a man page: + +- detect Secure Boot / lockdown / mokutil state +- generate a machine-local key on request +- print the exact `mokutil --import` / reboot / MokManager steps +- optionally hook DKMS so NVIDIA modules get signed with that key +- refuse to call this “Secure Boot support” in Welcome or on the website + +That is on-brand with Fireproof: simulate, explain, do not lie about the +boundary. + +### 3. Debian's already-signed chain — the only path that can boot SB-on without our keys + +Debian's `shim-signed` is Microsoft-signed and trusts Debian's vendor +key. Debian's `grub-efi-amd64-signed` and `linux-image-amd64` are signed +by that key. A derivative that **does not replace those signed EFI +binaries** can boot with Secure Boot on by riding Debian's chain. + +That is not a Shadowfetch Microsoft-trusted shim. It is “we boot because +Debian already did the signing programme.” If 3.6 ever claims a result +here, the sentence has to stay that ugly. + +What would have to be true, and is not true today: + +| Requirement | 3.5.0 state | +| --- | --- | +| Live ISO first-stage is Debian shim (`BOOTX64.EFI`) | live-build GRUB2, unsigned | +| Installed ESP first-stage is Debian shim | `sf-install-grub` installs unsigned GRUB, `--removable --no-nvram` | +| GRUB EFI binary is `grub-efi-amd64-signed` | package list has `grub-efi-amd64` | +| Kernel is Debian-signed `linux-image-amd64` | already true; do not replace it with an unsigned custom kernel | +| Umbra GRUB **theme** does not replace the signed EFI binary | theme is assets + `grub.cfg`; that part can stay | +| Out-of-tree modules under lockdown | NVIDIA DKMS will fail until a MOK signs them | +| A signed-boot QA case | 3.5.0's 11 gates do not include one | + +Even a successful Debian-chain boot is a **narrow** win: + +- Firmware trusts Microsoft, which trusts Debian's shim, which trusts + Debian's GRUB and kernel. Shadowfetch userspace, Calamares config, and + the Umbra theme are not in that signature. +- Debian testing will move GRUB and the kernel. We inherit their + signatures and their regressions. We do not re-sign. +- Custom GRUB modules, a rebuilt `grubx64.efi`, or a live-build layout + that copies unsigned GRUB over the signed one will fail closed. +- Phoenix snapshot boot via `grub-btrfs` loads extra GRUB config from + snapshot subvolumes. That is a GRUB script concern, not a signed-binary + concern, but it has to be re-tested with Secure Boot and lockdown on. + Do not assume it still works. +- Lockdown will refuse unsigned proprietary NVIDIA modules. The public + Secure Boot page already names this as the reason NVIDIA “just works” + today. Turning Secure Boot on without a MOK path is a graphics + regression for the hardware we actually care about. + +ISO-size note for this path: shim + signed GRUB are a few megabytes, not +the budget problem. The budget problem is duplicating boot payloads +(see UKI). + +### 4. UKI — research, not a 3.6 default + +A Unified Kernel Image is a single PE file: kernel + initrd + cmdline, +optionally signed. It is the clean end-state if we later have a key +(MOK or, much later, a Microsoft-signed shim that trusts a Shadowfetch +key). It is a poor 3.6 default. + +- Size. A desktop initrd is large. A UKI is that initrd again, plus the + kernel, sitting on the ESP or in the ISO. On a 3.98 GB image this is + how you lose the 4 GiB fight. +- Bootloader. Replacing GRUB with systemd-boot A/B (the old Tier 5 + idea) fights `grub-btrfs` and the Phoenix “boot this snapshot” + contract we just finished shipping. 3.6 will not trade rollback for a + prettier EFI binary. +- Live ISO. live-build's current GRUB2 live path is not a UKI path. + Teaching the live USB to boot a UKI is a different installer, not a + config drop. +- Signing. A UKI signed with a key firmware does not trust is a file, + not a Secure Boot solution. Same as today. + +Leave UKI as a measured experiment on an installed VM: build one with +`ukify` from the already-shipped Debian kernel, sign it with a +**throwaway lab key**, enroll that key in a QEMU OVMF `db` or MOK, and +record size + boot. Do not bake the result into the ISO unless the +squashfs measurement says it fits **and** GRUB snapshot-boot still +works. That measurement does not exist yet. + +## ISO-size constraint + +Hard numbers from the shipped 3.5.0 artifact: + +- ISO: `shadowfetch-3.5.0-amd64.iso` +- Size: `3,980,310,528` bytes (3.98 GB / 3.71 GiB) +- SHA-256: `2af853b1f5dedfca17a7a63783f4c881e72e912f26082b10c07d45aafe57b995` +- Ceiling: 4 GiB (`4,294,967,296` bytes) — FAT32 single-file / ISO-9660 + per-file limit the project already treats as binding +- ISO-file headroom: `314,656,768` bytes (~300 MiB) + +That 300 MiB is **not** spendable cash. The squashfs inside the ISO is +the file that actually hits the per-file limit. An older live-build +comment (`firmware-sof-signed` in `shadowfetch-core.list.chroot`) already +warned that squashfs headroom was on the order of tens of mebibytes +after firmware. 3.5.0's ISO is larger than 3.0.0's +(`3,967,508,480` bytes). We do not have a published 3.5.0 +`filesystem.squashfs` size in-tree. **Measure it before adding any boot +payload.** The rule in that comment still stands: anything further needs +something removed first. + +Practical budget for a later 3.6 implementation: + +| Change | Likely size | Fits? | +| --- | --- | --- | +| Docs / Welcome / Calamares copy | ~0 | yes | +| `mokutil` (already shipped) | 0 | already in | +| `sbsigntool` / `efitools` as **optional post-install** | small; keep out of squashfs if possible | maybe, if measured | +| Debian `grub-efi-amd64-signed` + shim as ESP first-stage | a few MiB | probably, if it **replaces** unsigned GRUB instead of duplicating it | +| Extra unsigned+signed bootloader copies “just in case” | adds up | no, unless something else leaves | +| UKI (kernel + desktop initrd) on the ISO | tens to hundreds of MiB | assume no until measured | +| NVIDIA signed modules, extra kernels, systemd-boot + GRUB | large | out | + +Bake config. Download bulk. Do not put a second initrd on the live image +to look modern. + +## Risks + +- **Claim drift.** “Secure Boot ready,” “signed boot,” or removing + known-issues #1 because we shipped `mokutil` or Debian's shim package + is a lie. The firmware either accepts the USB or it does not. +- **Debian-chain honesty.** If we ever boot through Debian's shim, say + that. Do not rebrand it as a Shadowfetch Microsoft signature. +- **NVIDIA / lockdown.** Secure Boot on ⇒ kernel lockdown ⇒ unsigned + DKMS fails. The current “disable Secure Boot” story is also the + current NVIDIA story. A 3.6 SB-on path without a MOK hook is a + graphics regression. +- **Dual-boot BitLocker.** Changing Secure Boot state seals Windows out + until the 48-digit recovery key is entered. The public guide already + leads with this. Any new helper must too. +- **Chicken-and-egg live USB.** MOK enrollment cannot fix “the USB does + not appear in the boot menu.” That is why firmware-disable remains the + supported install path even if an installed Debian-chain path later + works. +- **Custom GRUB vs signatures.** Umbra theme files are fine. Replacing + or wrapping `grubx64.efi` is not. live-build will happily emit an + unsigned layout if we are not explicit. +- **`--removable --no-nvram`.** The installer avoids writing NVRAM boot + entries. A signed-chain install has to decide whether shim still lands + as `\EFI\BOOT\BOOTX64.EFI` (removable) or as a vendor path with a + BootXXXX entry. Wrong choice = “installed but firmware still cannot + see it.” +- **Phoenix / grub-btrfs.** Snapshot-boot is a shipped 3.5 contract. + Secure Boot work that breaks it is a net loss. +- **Key handling.** There is no Microsoft signing key, no Shadowfetch + UEFI CA, and no excuse to commit a generated key “for later.” Lab + keys stay on the lab machine. +- **Debian testing.** Signed Debian packages will change under us. + Fireproof still does not make testing into stable. +- **QA gap.** 3.5.0 acceptance is BIOS Fire + UEFI Ice with Secure Boot + off. A signed-boot claim needs a Secure-Boot-on VM (OVMF with `db` + that matches the chain under test) **and** at least one physical + machine. Virtual Mesa is not that test, same rule as NVIDIA. + +## What stays out of 3.6 + +- Microsoft third-party UEFI CA submission, a Shadowfetch-branded + signed shim, and any date for that queue. The public page already + calls this a standing commitment with someone else's calendar. +- Inventing, generating-for-the-repo, or documenting fake Microsoft / + Secure Boot signing keys. +- Rebuilding the 3.5.0 ISO or changing live-build package lists as part + of this planning work. +- Declaring known-issues #1 fixed. +- UKI as the default live or installed boot path. +- systemd-boot A/B as a GRUB replacement. +- TPM2 LUKS auto-unlock, USBGuard, dnscrypt, amnesic live mode, and the + rest of the old Tier 5 “Hardened edition” pile. +- Re-litigating Phoenix / Fireproof as the 3.6 flagship. +- Agent Oasis, gaming spin, baked models, or any other ISO-growing + feature parked in older roadmaps. +- Website copy that says “Secure Boot supported” without a named + signed-boot test that passed. + +## Suggested 3.6 shape (when implementation is actually authorized) + +Planning recommendation, not a schedule: + +1. **Keep** firmware-disable as the documented, supported install path. +2. **Add** live-session / installer / Passport wording that matches the + public guide. No new packages required. +3. **Measure** `filesystem.squashfs` and ESP contents on the 3.5.0 ISO + before touching boot packages. +4. **Investigate** (do not advertise) installing Debian + `shim-signed` + `grub-efi-amd64-signed` as the **installed** UEFI + first-stage, replacing unsigned `grub-install`, still `--removable` + unless a test shows NVRAM is required. Success metric: a Secure + Boot-on OVMF guest boots the **installed** disk using Debian's + signatures. Failure is allowed and should be written down. +5. **If and only if** (4) works, add a machine-local MOK helper for + DKMS / NVIDIA. Success metric: lockdown on, NVIDIA module loads + after enrollment, Phoenix Point still wraps the driver transaction. +6. **UKI** stays a lab note until size + grub-btrfs are proven. +7. **Public claim change** is a separate publication decision after a + signed-boot gate exists. Until then known-issues #1 stays #1. + +3.6 can be a real differentiator among Debian+KDE derivatives if it +makes the trust chain **legible and testable**. It cannot be “we got +Microsoft to sign our shim.” We do not have that, and this plan will +not pretend we do. diff --git a/next-release/README.md b/next-release/README.md index 26a30dc..eefb52d 100644 --- a/next-release/README.md +++ b/next-release/README.md @@ -1,8 +1,20 @@ -# Staged for 2.2.0 — not shipped +# next-release/ -Files here are finished and tested but deliberately NOT in any package. -`debian/*.install` lists every shipped file explicitly by path, so nothing in -this directory can reach a build by accident. +Planning notes and staged files that are deliberately **not** in any +package. `debian/*.install` lists every shipped file explicitly by path, so +nothing in this directory can reach a build by accident. + +## 3.6 planning + +- [`3.6-secure-boot.md`](3.6-secure-boot.md) — what 3.6 can honestly do + about known-issues #1 (unsigned Secure Boot) without Microsoft-trusted + keys, without rebuilding the 3.5.0 ISO, and without spending the last + of the 4 GiB budget. Phoenix/Fireproof snapshot rollback is already + shipped in 3.5.0; this note does not re-open that bet. + +## Staged for 2.2.0 — not shipped + +Finished and tested binaries, still not in any package. ## shadowfetch-hardware