3.6 Secure Boot — implementation gates (from PR #3 plan) #4

Activity

1. cursor

   added a commit that references this issue on Oct 16, 2026

   docs: rebase 3.6 Secure Boot plan on main and align with #4

   ...

   47fce08
2. ShadowfetchStudio commented on Oct 16, 2026

   

   ShadowfetchStudio

   on Oct 16, 2026

   OwnerAuthor

   More actions

   PR #3 is now on current main (5.0.1) and marked ready for review. The plan in next-release/3.6-secure-boot.md maps 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, --removable vs NVRAM, installed-only vs live USB, publication copy, and the Microsoft CA queue (still out of this track).
3. ShadowfetchStudio

   added a commit that references this issue on Oct 16, 2026

   3.6 planning: Secure Boot without Microsoft-trusted keys (#3)

   ...

   a59e470
4. ShadowfetchStudio commented on Oct 24, 2026

   

   ShadowfetchStudio

   on Oct 24, 2026 – with Cursor

   OwnerAuthor

   More actions

   Morning-rundown follow-up (judgment pass — recommendations only, not decisions). Gate 0 is done: PR #3 is merged (a59e470). Issue stays open.

   Recommended defaults (safe / matches existing direction)

   Labeled as recommendations. Nothing below authorizes live-build edits, ISO rebuilds, or site copy changes.

   1. Ship vehicle — Recommend: keep calling this the 3.6 track (planning / spike track), not a fake next ISO number. 5.0.1 is APT-only and cannot carry a bootloader change. Name the actual ride (later 5.x / 6.x) only after a spike result exists.
   2. Authorize the Debian-chain spike — Recommend: yes, lab-only. Installed-disk spike with Debian shim-signed + grub-efi-amd64-signed, replacing unsigned sf-install-grub. Prefer --removable first. Failure is allowed and should be written down. No live-build edit on main until that spike is green (or explicitly abandoned).
   3. --removable --no-nvram vs NVRAM — Recommend: keep the plan default (removable / no NVRAM) unless the spike only boots with a BootXXXX entry. If NVRAM is required, that is a product change to sf-install-grub — escalate then, do not silently flip.
   4. Installed-only vs live USB — Recommend: pursue the installed-only Debian-chain path as the engineering spike. Until the installer USB itself boots SB-on, firmware-disable remains the only supported public install path. An installed-only win is still valuable; it is not enough for a “Secure Boot supported” claim covering the USB.
   5. Publication — Recommend: do not touch site / known-issues / README copy until a named Secure-Boot-on gate exists (OVMF + at least one physical machine). Known-issues Repo cleanup for the 2.1.5 reviewer pass #1 stays Repo cleanup for the 2.1.5 reviewer pass #1. Rewriting the public “Will this be fixed” (Microsoft-signed Shadowfetch shim) sentence is part of the publication call, not a side effect of the spike.
   6. Microsoft third-party CA queue — Recommend: leave out of this track (matches “Explicitly out for 3.6”). If it should run in parallel as a standing commitment, that needs an explicit “start the queue” call — do not smuggle it into the Debian-chain spike.

   Still needs your call

   All six remain yours to confirm or override. Highest leverage first:

   • (2) Authorize the lab spike? — without this, gates stay blocked.
   • (1) Track vs named ISO vehicle once you want a ship target.
   • (4)/(5) how much (if anything) to say publicly for an installed-only win.
   • (3) only if the spike forces NVRAM.
   • (6) only if you want the Microsoft CA queue started in parallel.

   Non-negotiables from the plan still hold: no invented Microsoft / Shadowfetch UEFI keys, no trading Phoenix / grub-btrfs for a prettier EFI path, no “Secure Boot supported” claim without the named test.

   Not closing this issue.