From dff36e88dd81cee8655749b275d2d22a5838aa5f Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Thu, 3 Sep 2026 17:43:34 +0000 Subject: [PATCH 1/2] 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 From 47fce087e355a7a0b9c823b186a2318e08c902ca Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Fri, 16 Oct 2026 15:46:22 +0000 Subject: [PATCH 2/2] docs: rebase 3.6 Secure Boot plan on main and align with #4 Rebaseline the planning note to the 5.0.0 ISO / 5.0.1 tree, map the implementation gates 1:1 with issue #4, and record what already landed (per-machine DKMS MOK, published squashfs size). Planning only; does not authorize a spike, ISO rebuild, or claim change. Co-authored-by: Shadowfetch Studio --- next-release/3.6-secure-boot.md | 383 +++++++++++++++++++++----------- next-release/README.md | 18 +- 2 files changed, 269 insertions(+), 132 deletions(-) diff --git a/next-release/3.6-secure-boot.md b/next-release/3.6-secure-boot.md index db757f9..e6efe86 100644 --- a/next-release/3.6-secure-boot.md +++ b/next-release/3.6-secure-boot.md @@ -1,48 +1,81 @@ # 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. +Status: **planning only.** Do not treat this file as a build brief, a +package list, or a permission to rebuild the ISO. Do not change +live-build, do not invent Microsoft or Shadowfetch UEFI signing keys, +and do not change public claims until the gates below say so. + +This is the repo record for the Secure Boot track originally scoped as +“3.6”. Implementation tracking is +[issue #4](https://github.com/ShadowfetchStudio/shadowfetch-linux/issues/4). +This file is the engineering plan; #4 is the checklist. They must stay +consistent. Landing this file on `main` is gate 0 of #4 — it does not +authorize a spike, an ISO rebuild, or a website change. + +The current public ISO is **5.0.0**. **5.0.1** is an APT-only update +(no new ISO). 4.0, 4.1, 5.0.0, and 5.0.1 all shipped after this track +was named 3.6, and none of them closed the unsigned-Secure-Boot caveat. +The track name stays “3.6” until Robert decides the ship vehicle (see +[Open items](#open-items-and-roberts-decisions)). Public source of truth today: -- [Known issues](https://www.shadowfetchlinux.org/known-issues) — issue #1 +- [Known issues](https://www.shadowfetchlinux.org/known-issues) — + “Secure Boot is not signed” is currently item **#18** (5.0 numbering). + Issue #4 still calls it “#1” from the 3.5 known-issues list. A + numbering change is not a claim change. The caveat stays published + until a named Secure-Boot-on test passes. - [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) +- Repo README hardware-and-limits line, same claim +- `docs/GITHUB-CLAIM-SOURCES.md` — do not claim Secure Boot support + unless a signed-boot test is added and passes + +This document does not change those pages. + +## Non-negotiables (from issue #4) + +- The unsigned-Secure-Boot caveat stays on the known-issues page until + a named Secure-Boot-on test passes. Do not treat a list reorder as + fixing it. +- No website claim of “Secure Boot supported” without that test. +- Do not invent Microsoft or Shadowfetch UEFI signing keys. Do not + commit a generated key “for later.” Lab keys stay on the lab machine. +- Do not trade Phoenix / `grub-btrfs` snapshot-boot for a prettier EFI + path. +- Planning only: no live-build edits and no ISO rebuild until the + gates below say so. + +## What already shipped (so we do not re-bet it) + +Phoenix + Fireproof + `grub-btrfs` snapshot-boot shipped in 3.5.0 and +are still the 5.0 contract. Residual Phoenix work in +`docs/FIRE_ROADMAP.md` (ext4 “Phoenix Lite”, `@home` protection, +scheduled timelines, qgroup accounting) is polish, not the missing +trust-chain differentiator. 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. +boot-to-snapshot rollback** as an open signature bet, and **Secure Boot +w/ custom MOK + signed kernels/UKI** as a Tier 5 hardened-edition item. +That document is a post-1.0.6 backlog. It is stale. Secure Boot is the +actual next trust-chain gap. This track will not re-open snapshots, and +it will not take UKI or systemd-boot A/B as a 3.6 default. -Verified against the 3.5.0 tree and the published 3.5.0 contract -(`RELEASE-3.5.0.md`, repo README, known-issues #3): +Verified against the 5.0.0 tree (`RELEASE-5.0.0.md`, repo README, +`qa/5.0.0/acceptance.json`): -| Old backlog item | 3.5.0 fact | +| Old backlog item | 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. | +| “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. 5.0.1 is the current Fireproof. | +| Shared ISO-wide DKMS MOK | 4.x ISOs shipped `/var/lib/dkms/mok.key`. 5.0.0 scrubs that at image-build time; each machine generates its own key the first time DKMS builds a module. `shadowfetch-doctor` (`sec.dkms_mok`) and a one-time desktop notice cover upgrades that still have the shared key. | +| NVIDIA + MOK helper | `shadowfetch-gpu` already offers `mokutil --import` when it thinks Secure Boot is on. That is a DKMS enrollment helper, not a firmware first-stage. It cannot make the live USB appear, and it cannot boot unsigned GRUB. | +| Signed-boot QA | 5.0.0 acceptance (`qa/5.0.0/acceptance.json`) has no Secure-Boot-on case. INSTALL-01 is BIOS and UEFI with Secure Boot off. Virtual Mesa is not that test. | -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 original 3.6 draft already said a project-wide MOK baked into the +ISO is not a secret. 5.0.0 closed that hole. It did not close +known-issues Secure Boot. ## The problem, stated without marketing @@ -60,18 +93,18 @@ Shadowfetch has: - 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. +The published guide is still 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 +through that shim. 5.0 still 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 +grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable --no-nvram --recheck ``` That is `sf-install-grub`. It installs `grub-efi-amd64`, not @@ -80,9 +113,9 @@ 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. +still unsigned. The known-issues caveat remains true. -## What 3.6 can honestly ship +## What this track 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 @@ -90,16 +123,16 @@ planning change. ### 1. Keep telling people to disable Secure Boot -Already published. Keep it as the supported path for 3.6. +Already published. Keep it as the supported install path until a +named Secure-Boot-on test passes — including after 5.0. 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. +BitLocker recovery-key demand, Windows 11 “unsupported” noise, kernel +lockdown / proprietary NVIDIA modules, 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: +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 @@ -112,14 +145,14 @@ story: - 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. +This is the only 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: +Honest limits, unchanged by 5.0: - MokManager is a shim feature. No running shim means no MokManager. Enrolling a MOK therefore requires either Debian's already-signed shim @@ -128,26 +161,24 @@ Honest limits: - 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.” + 5.0.0 already refuses to ship one (`iso_gate` `MACHINE_SECRET_PATH` + and the image-build scrub). Do not put one back. +- A per-machine key generated at first DKMS build is the only MOK story + that is not theater. 5.0.0 already does that. 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: +Issue #4's MOK gate is therefore **not** “invent per-machine keys” +(done). It is: **if and only if** the Debian-chain spike works, hook +DKMS / NVIDIA under lockdown so the module loads after enrollment, and +keep Phoenix Point wrapping the driver transaction. +`shadowfetch-gpu` already starts that enrollment conversation; it still +needs a running shim and a Secure-Boot-on retest. -- 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. +Refuse to call this “Secure Boot support” in Welcome or on the website. ### 3. Debian's already-signed chain — the only path that can boot SB-on without our keys @@ -157,20 +188,20 @@ 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. +Debian already did the signing programme.” If this track ever claims a +result here, the sentence has to stay that ugly. -What would have to be true, and is not true today: +What would have to be true, and is not true on 5.0.0: -| Requirement | 3.5.0 state | +| Requirement | 5.0.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 | +| Out-of-tree modules under lockdown | NVIDIA DKMS will fail until a MOK signs them; 5.0 generates a per-machine key but there is still no running shim | +| A signed-boot QA case | 5.0.0's acceptance cases do not include one | Even a successful Debian-chain boot is a **narrow** win: @@ -185,29 +216,38 @@ Even a successful Debian-chain boot is a **narrow** win: 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. +- Lockdown will refuse unsigned proprietary NVIDIA modules. Turning + Secure Boot on without a working MOK path is a graphics regression for + the hardware we actually care about. +- The live USB chicken-and-egg remains: an installed-disk win does not + make the installer USB appear in a Secure-Boot-on firmware menu. + Firmware-disable stays the supported **install** path even if an + installed Debian-chain path later works. ISO-size note for this path: shim + signed GRUB are a few megabytes, not -the budget problem. The budget problem is duplicating boot payloads +the budget problem, **if they replace unsigned GRUB instead of +duplicating it**. The budget problem is duplicating boot payloads (see UKI). -### 4. UKI — research, not a 3.6 default +Issue #4 scopes the spike as **installed** UEFI first-stage, lab only, +prefer `--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 must be written down. + +### 4. UKI — research, not a 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. +key). It is a poor default for this track. - 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 + kernel, sitting on the ESP or in the ISO. On a 4.09 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. + contract. This track 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. @@ -219,35 +259,50 @@ Leave UKI as a measured experiment on an installed VM: build one with **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. +works. + +Issue #4 lists UKI-as-default as explicitly out. ## ISO-size constraint -Hard numbers from the shipped 3.5.0 artifact: +Hard numbers from the **current** public ISO (`RELEASE-5.0.0.md`, +`qa/5.0.0/acceptance.json`). 5.0.1 did not publish a new ISO. -- ISO: `shadowfetch-3.5.0-amd64.iso` -- Size: `3,980,310,528` bytes (3.98 GB / 3.71 GiB) -- SHA-256: `2af853b1f5dedfca17a7a63783f4c881e72e912f26082b10c07d45aafe57b995` +- ISO: `shadowfetch-5.0.0-amd64.iso` +- Size: `4,085,778,432` bytes (4.09 GB / 3.81 GiB) +- SHA-256: `2d8a72e044e8061bd616b2b4668425cc4d4ec0480a98975f961c0e58cba95e21` +- Squashfs: `3,830,738,944` bytes (published in `RELEASE-5.0.0.md`) - 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: +- ISO-file headroom: `209,188,864` bytes (~200 MiB) +- Squashfs-to-ceiling headroom: `464,228,352` bytes (~443 MiB) + +Issue #4 originally asked to measure the **3.5.0** ISO +(`3,980,310,528` bytes / sha256 `2af853b1…`). Those ISO-level numbers +are in `RELEASE-3.5.0.md`. The 3.5.0 `filesystem.squashfs` size is +still not published in-tree. ESP contents are not published for 3.5.0 +or 5.0.0. + +The 5.0.0 squashfs size **is** now in-tree. That satisfies the squashfs +half of the measure gate for the ISO we would actually change. It does +not satisfy ESP contents. **Do not add boot payloads until ESP +contents on the 5.0.0 image are written down.** The ISO-file headroom +(~200 MiB) is **not** spendable cash; duplicating bootloaders or +adding a UKI is how you lose. + +An older live-build comment (`firmware-sof-signed` in +`shadowfetch-core.list.chroot`) warned squashfs headroom was ~41 MiB +after firmware. 5.0.0's published squashfs is the number to use now. +The rule in that comment still stands for *new* bulk: check +`ls -la filesystem.squashfs` after a build before adding more. + +Practical budget for a later implementation: | Change | Likely size | Fits? | | --- | --- | --- | | Docs / Welcome / Calamares copy | ~0 | yes | | `mokutil` (already shipped) | 0 | already in | +| Per-machine DKMS MOK (5.0.0) | 0 on the ISO | already in; do not bake a shared key | | `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 | @@ -257,17 +312,35 @@ Practical budget for a later 3.6 implementation: Bake config. Download bulk. Do not put a second initrd on the live image to look modern. +## Implementation gates (issue #4, current state) + +These are the #4 checklist, restated against 5.0. None of them are +done except the squashfs *number* now being published. Checking a box +on #4 happens when the work exists, not when this file is edited. + +| # | Gate | State | +| --- | --- | --- | +| 0 | Merge PR #3 (or land this file on `main`) so the plan is the repo record | Open. This PR is the vehicle. Do not treat a ready-for-review mark as a merge. | +| 1 | Measure `filesystem.squashfs` + ESP contents before adding boot payloads | Partial. 5.0.0 squashfs `3,830,738,944` bytes is in `RELEASE-5.0.0.md`. 3.5.0 squashfs still unpublished. ESP contents unpublished on both. Remaining: write ESP layout/sizes from the 5.0.0 ISO. | +| 2 | Spike (lab only): Debian `shim-signed` + `grub-efi-amd64-signed` as **installed** UEFI first-stage, replacing unsigned `sf-install-grub`; prefer `--removable` unless a test shows NVRAM is required | Open. Not authorized by this file. Needs Robert (see below). | +| 3 | Success metric for the spike: Secure Boot-on OVMF guest boots the **installed** disk on Debian's signatures. Failure is allowed — write it down | Open. Depends on gate 2. | +| 4 | If and only if the spike works: machine-local MOK helper for DKMS / NVIDIA under lockdown; Phoenix Point still wraps the driver transaction | Partial precursor only. 5.0 already generates a per-machine DKMS key and `shadowfetch-gpu` can offer `mokutil --import`. The IFF condition (running Debian shim, lockdown-on NVIDIA load, Phoenix wrap) is not met. | +| 5 | Re-test Phoenix / `grub-btrfs` snapshot-boot with Secure Boot + lockdown on | Open. Depends on gate 2 succeeding. | +| 6 | Add a Secure-Boot-on acceptance gate (OVMF **and** at least one physical machine). Virtual Mesa alone is not enough | Open. 5.0.0 has no such case. | +| 7 | Separate publication decision for site / known-issues copy — only after the gate exists | Open. Robert. Until then the caveat stays published (currently known-issues #18). | + ## 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. +- **Claim drift.** “Secure Boot ready,” “signed boot,” or removing the + known-issues caveat because we shipped `mokutil`, Debian's shim + *package*, or a per-machine DKMS key 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. + current NVIDIA story. An 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. @@ -282,62 +355,122 @@ to look modern. 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. + see it.” If the spike only works with NVRAM, that is Robert's call, + not a silent installer change. +- **Phoenix / grub-btrfs.** Snapshot-boot is a shipped 3.5/5.0 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. + keys stay on the lab machine. Do not regress the 5.0.0 shared-MOK + scrub. - **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. +- **QA gap.** 5.0.0 acceptance is BIOS + UEFI 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. +- **Stale 3.6 version label.** Shipping 4.x and 5.x without this work + does not make the caveat go away. It does mean “3.6” is a track name, + not the next ISO number, until Robert names the vehicle. -## What stays out of 3.6 +## What stays out of this track (issue #4) - 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. +- Rebuilding the 5.0.0 ISO, rebuilding 3.5.0 “just to try,” or changing + live-build package lists as part of this planning work. +- Declaring the known-issues Secure Boot caveat fixed, including by + claiming that shipping `mokutil` / `shim-signed` packages fixed it. - 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. +- Re-litigating Phoenix / Fireproof as the flagship of this track. - 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) +## Suggested shape (when implementation is actually authorized) -Planning recommendation, not a schedule: +Planning recommendation, not a schedule. Matches issue #4. 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. +3. **Finish measuring** ESP contents on the 5.0.0 ISO (squashfs size is + already published) 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 +5. **If and only if** (4) works, complete the machine-local MOK path + for DKMS / NVIDIA under lockdown. Success metric: lockdown on, + NVIDIA module loads after enrollment, Phoenix Point still wraps the + driver transaction. +6. **Re-test** Phoenix / `grub-btrfs` snapshot-boot with Secure Boot + and lockdown on. +7. **UKI** stays a lab note until size + grub-btrfs are proven. Not a + default. +8. **Public claim change** is a separate publication decision after a + signed-boot gate exists (OVMF + one physical machine). Until then + the known-issues caveat stays published. + +This track 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. + +## Open items and Robert's decisions + +Still open after this planning note. None of these close issue #4. + +Engineering remaining (not a founder call until they block): + +- ESP contents on `shadowfetch-5.0.0-amd64.iso` — layout and sizes, + written into this plan or a follow-up note before any boot-payload + change. +- 3.5.0 `filesystem.squashfs` size, if anyone still wants the + historical comparison #4 originally asked for. Not required to + change 5.0.0. +- Lab spike result (pass or fail), once authorized. +- Phoenix / `grub-btrfs` retest under SB + lockdown, once the spike + exists. +- Named Secure-Boot-on acceptance case (OVMF + one physical machine). + +Robert decides: + +1. **Ship vehicle.** Keep calling this the 3.6 track, or name the ISO + it would actually ride (a later 5.x image, a 6.x, or “planning + until the spike exists”). 5.0.1 is APT-only and cannot carry a + bootloader change. +2. **Authorize the Debian-chain spike.** This file does not. Gate 2 + stays lab-only, installed-disk only, no live-build edit on `main` + until that call. +3. **`--removable --no-nvram` vs NVRAM.** #4 prefers removable unless + a test shows NVRAM is required. If the spike only boots with a + BootXXXX entry, that is a product change to `sf-install-grub`, not + an engineer default. +4. **Installed-only vs live USB.** Even a passing installed spike does + not sign the installer USB. Decide whether an installed-only + Debian-chain path is worth any public sentence, or whether + firmware-disable remains the only supported path until the USB + itself boots SB-on. +5. **Publication.** Site / known-issues / README wording after a + named gate exists. Separate from the spike. Default: do not touch + copy. The public “Will this be fixed” section currently describes + a Microsoft-signed Shadowfetch shim with no date; it does not + mention riding Debian's chain. Rewriting that sentence is part of + this decision, not a side effect of merging this file. +6. **Microsoft third-party CA queue.** Explicitly out of this track. + Starting that submission is a standing commitment on someone else's + calendar. Say so if it should run in parallel; do not smuggle it + into the 3.6 spike. + +Pam opened #4 after first-plate review with Candice. This plan does not +close that issue and does not merge itself. diff --git a/next-release/README.md b/next-release/README.md index eefb52d..e439c91 100644 --- a/next-release/README.md +++ b/next-release/README.md @@ -4,13 +4,17 @@ 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. +## 3.6 planning (Secure Boot track) + +- [`3.6-secure-boot.md`](3.6-secure-boot.md) — what this track can + honestly do about unsigned Secure Boot without Microsoft-trusted + keys, without rebuilding the 5.0.0 ISO, and without spending the + last of the 4 GiB budget. Implementation gates live in + [issue #4](https://github.com/ShadowfetchStudio/shadowfetch-linux/issues/4). + Phoenix/Fireproof snapshot rollback already shipped in 3.5.0 and is + still the 5.0 contract; this note does not re-open that bet. The + public known-issues caveat is currently #18 on the 5.0 page; a + numbering change is not a claim change. ## Staged for 2.2.0 — not shipped