diff --git a/next-release/3.6-secure-boot.md b/next-release/3.6-secure-boot.md new file mode 100644 index 0000000..e6efe86 --- /dev/null +++ b/next-release/3.6-secure-boot.md @@ -0,0 +1,476 @@ +# 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. 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) — + “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 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 **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 5.0.0 tree (`RELEASE-5.0.0.md`, repo README, +`qa/5.0.0/acceptance.json`): + +| 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. 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 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 + +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 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. 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 --recheck +``` + +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. The known-issues caveat remains true. + +## 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 +planning change. + +### 1. Keep telling people to disable Secure Boot + +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, 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. + +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 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, 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 + 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. + 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. + +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. + +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 + +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 this track ever claims a +result here, the sentence has to stay that ugly. + +What would have to be true, and is not true on 5.0.0: + +| 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; 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: + +- 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. 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, **if they replace unsigned GRUB instead of +duplicating it**. The budget problem is duplicating boot payloads +(see UKI). + +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 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 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. 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. +- 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. + +Issue #4 lists UKI-as-default as explicitly out. + +## ISO-size constraint + +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-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: `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 | +| 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. + +## 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 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. 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. +- **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.” 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. 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.** 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 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 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 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 shape (when implementation is actually authorized) + +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. **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, 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 26a30dc..e439c91 100644 --- a/next-release/README.md +++ b/next-release/README.md @@ -1,8 +1,24 @@ -# 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 (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 + +Finished and tested binaries, still not in any package. ## shadowfetch-hardware