3.6 planning: Secure Boot without Microsoft-trusted keys

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.

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