Repository navigation
3.6 Secure Boot — implementation gates (from PR #3 plan) #4
Description
Tracking checklist for turning the 3.6 Secure Boot planning note into a real ship.
Source of truth: draft PR #3 (next-release/3.6-secure-boot.md). Planning only — no live-build edits and no ISO rebuild until the gates below say so.
Non-negotiables
- Known-issues Repo cleanup for the 2.1.5 reviewer pass #1 stays Repo cleanup for the 2.1.5 reviewer pass #1 until a named Secure-Boot-on test passes.
- No website claim of “Secure Boot supported” without that test (
docs/GITHUB-CLAIM-SOURCES.md). - Do not invent Microsoft / Shadowfetch UEFI signing keys.
- Do not trade Phoenix /
grub-btrfssnapshot-boot for a prettier EFI path.
Gates
- Merge PR 3.6 planning: Secure Boot without Microsoft-trusted keys #3 (or land the planning docs on
main) so the plan is the repo record. - Measure
filesystem.squashfs+ ESP contents on the shipped 3.5.0 ISO (3,980,310,528bytes / sha2562af853b1…). Write numbers into the plan before adding boot payloads. - Spike (lab only): install Debian
shim-signed+grub-efi-amd64-signedas installed UEFI first-stage, replacing unsignedsf-install-grub, prefer--removableunless a test shows NVRAM is required. - Success metric for spike: Secure Boot-on OVMF guest boots the installed disk on Debian’s signatures. Failure is allowed — write it down.
- If and only if the spike works: machine-local MOK helper for DKMS / NVIDIA under lockdown; Phoenix Point still wraps the driver transaction.
- Re-test Phoenix /
grub-btrfssnapshot-boot with Secure Boot + lockdown on. - Add a Secure-Boot-on acceptance gate (OVMF + at least one physical machine). Virtual Mesa alone is not enough.
- Separate publication decision for site/known-issues copy — only after the gate exists.
Explicitly out for 3.6
Microsoft third-party CA / Shadowfetch-branded shim, UKI as default, systemd-boot A/B replacing GRUB, rebuilding 3.5.0 “just to try,” and any claim that shipping mokutil / shim-signed packages fixed known-issues #1.
Opened by Pam (VP ops) after first-plate review with Candice.
Activity
docs: rebase 3.6 Secure Boot plan on main and align with #4
ShadowfetchStudio commentedon Oct 16, 2026
PR #3 is now on current
main(5.0.1) and marked ready for review. The plan innext-release/3.6-secure-boot.mdmaps the gates below 1:1 and records what 5.0 already did (per-machine DKMS MOK, published squashfs size).This issue stays open. Gate 0 (land the plan) is the PR; it is not merged. Remaining gates are still unchecked. Robert's open calls are listed at the end of the plan: ship vehicle, authorizing the Debian-chain spike,
--removablevs NVRAM, installed-only vs live USB, publication copy, and the Microsoft CA queue (still out of this track).3.6 planning: Secure Boot without Microsoft-trusted keys (#3)