The Windows signing docs still told users to import a certificate we no longer publish #238

Merged

enricobuehler merged 1 commits from worktree-docs-azure-signing-cert-import into main 2026-08-14 22:05:55 +00:00

Conversation 0 Commits 1 Files Changed 7

+85 -48

enricobuehler commented 2026-08-14 21:57:53 +00:00

Owner

Copy Link

Copy Source

Azure Artifact Signing chains to a publicly trusted root, so neither the host installer nor the client MSIX ships a .cer any more and users import nothing. Four docs pages still walked through importing one.

These instructions don't merely go stale — they still work. The pre-Azure .cer files are still sitting in the package registry, so the URLs the docs name return 200, not 404, and following them plants the retired self-signed CN=unom certificate (valid to 2036) into machine Root and TrustedPublisher for no reason at all.

Verified on glass first

Against the 0.29 canary on the Intel iGPU box, before any of this was written:

• host setup.exe and the client MSIX both verify Valid, subject = the Azure profile DN, chain unom → Microsoft ID Verified CS EOC CA 04 → PCA 2021 → Microsoft Identity Verification Root CA 2020, and that root is already in the machine store — so there is genuinely nothing to import
• both are timestamped, which is what keeps them valid past the 3.00-day leaf
• host installer: clean install, 0.28.1 → 0.29 upgrade, and uninstall all exit 0; the MSIX installs with nothing imported

What changed

install.md, install-client.md, windows-host.md, uninstall.md — the import steps are gone. Each page now explains how to remove a previously imported certificate and names its thumbprint (CD1EFDEE…) so the right one goes.

The driver certificate story is deliberately untouched: it is still self-signed, still planted by the installer into Root + TrustedPublisher, and still documented that way. Conflating the two was the easy mistake here.

Also corrected, all of it found during that testing:

• MSIX identity changed along with the publisher, so an install from 0.28.1 or earlier needs an uninstall rather than an upgrade — and because a packaged app's settings live inside the package, the client's identity and paired hosts go with it, so it pairs again once. (Confirmed in pf-client-core/src/trust.rs: %APPDATA%\punktfunk, which MSIX redirects into the package container.)
• A silent upgrade reuses the task selection the previous install recorded, not the wizard defaults — UsePreviousTasks defaults to yes and the .iss never sets it. Anything once declined stays declined: on a 0.20 box that meant driver install --gamepad never ran, the gamepad drivers stayed at the old protocol version, and the host logged a driver_proto=2 host_proto=3 mismatch with the virtual pad dead. Now documented, with the /MERGETASKS=… line that forces the full set.
• installaudiocable was still listed as a task name — retired in 4a621de6.
• Add-AppxPackage from a non-interactive session can fail 0x80070005; the real error is 0x80073D02 PACKAGES_IN_USE, because installing ours pulls a Microsoft.WindowsAppRuntime.2 update while it is in use.
• packaging/windows/README.md and clients/windows/packaging/README.md no longer claim a .cer is published, and the client README's canary version formula was still 0.3.<run_number>.0.
• windows-client.yml's header comment described only the old self-signed scheme; it now describes all three signing modes, Azure first.

Checks

bun run build (fumadocs/MDX) and bun run lint (tsc --noEmit) both green in docs-site; the edited workflow still parses as YAML.

Deliberately not in this PR

• The stale .cer files are still live in the registry. Deleting them from canary/ and latest/ for both punktfunk-host-windows and punktfunk-client-windows would make any old copy of the instructions fail loudly instead of quietly doing the wrong thing. That changes published artifacts, so it wants a separate decision.
• The release notes still need the uninstall-not-upgrade line — there is no 0.29 notes file yet.

Azure Artifact Signing chains to a publicly trusted root, so neither the host installer nor the client MSIX ships a `.cer` any more and users import nothing. Four docs pages still walked through importing one. These instructions don't merely go stale — they still *work*. The pre-Azure `.cer` files are still sitting in the package registry, so the URLs the docs name return **200, not 404**, and following them plants the retired self-signed `CN=unom` certificate (valid to 2036) into machine `Root` and `TrustedPublisher` for no reason at all. ## Verified on glass first Against the 0.29 canary on the Intel iGPU box, before any of this was written: - host `setup.exe` and the client MSIX both verify **Valid**, subject = the Azure profile DN, chain `unom → Microsoft ID Verified CS EOC CA 04 → PCA 2021 → Microsoft Identity Verification Root CA 2020`, and that root is already in the machine store — so there is genuinely nothing to import - **both are timestamped**, which is what keeps them valid past the 3.00-day leaf - host installer: clean install, `0.28.1 → 0.29` upgrade, and uninstall all exit 0; the MSIX installs with nothing imported ## What changed `install.md`, `install-client.md`, `windows-host.md`, `uninstall.md` — the import steps are gone. Each page now explains how to *remove* a previously imported certificate and names its thumbprint (`CD1EFDEE…`) so the right one goes. The **driver** certificate story is deliberately untouched: it is still self-signed, still planted by the installer into `Root` + `TrustedPublisher`, and still documented that way. Conflating the two was the easy mistake here. Also corrected, all of it found during that testing: - **MSIX identity changed along with the publisher**, so an install from 0.28.1 or earlier needs an uninstall rather than an upgrade — and because a packaged app's settings live inside the package, the client's identity and paired hosts go with it, so it pairs again once. (Confirmed in `pf-client-core/src/trust.rs`: `%APPDATA%\punktfunk`, which MSIX redirects into the package container.) - **A silent upgrade reuses the task selection the previous install recorded**, not the wizard defaults — `UsePreviousTasks` defaults to yes and the `.iss` never sets it. Anything once declined stays declined: on a 0.20 box that meant `driver install --gamepad` never ran, the gamepad drivers stayed at the old protocol version, and the host logged a `driver_proto=2 host_proto=3` mismatch with the virtual pad dead. Now documented, with the `/MERGETASKS=…` line that forces the full set. - `installaudiocable` was still listed as a task name — retired in 4a621de6. - `Add-AppxPackage` from a non-interactive session can fail `0x80070005`; the real error is `0x80073D02 PACKAGES_IN_USE`, because installing ours pulls a `Microsoft.WindowsAppRuntime.2` update while it is in use. - `packaging/windows/README.md` and `clients/windows/packaging/README.md` no longer claim a `.cer` is published, and the client README's canary version formula was still `0.3.<run_number>.0`. - `windows-client.yml`'s header comment described only the old self-signed scheme; it now describes all three signing modes, Azure first. ## Checks `bun run build` (fumadocs/MDX) and `bun run lint` (`tsc --noEmit`) both green in `docs-site`; the edited workflow still parses as YAML. ## Deliberately not in this PR - **The stale `.cer` files are still live in the registry.** Deleting them from `canary/` and `latest/` for both `punktfunk-host-windows` and `punktfunk-client-windows` would make any old copy of the instructions fail loudly instead of quietly doing the wrong thing. That changes published artifacts, so it wants a separate decision. - The release notes still need the uninstall-not-upgrade line — there is no 0.29 notes file yet.

enricobuehler added 1 commit 2026-08-14 21:57:55 +00:00

docs(windows): the signing pages still told users to import a certificate we no longer publish ... 55dbb14cf4

Azure Artifact Signing chains to a public root, so neither the host installer nor the client MSIX ships a .cer any more and users import nothing. install.md, install-client.md and windows-host.md still walked through importing one — and because the pre-Azure files are still sitting in the package registry those URLs return 200 rather than 404, so following the docs didn't fail loudly, it quietly planted a retired self-signed cert in machine Root and TrustedPublisher.

Verified on glass against the 0.29 canary while checking the release: both artifacts verify Valid, timestamped, and publicly trusted, and the MSIX installs with nothing imported.

Also corrected while here: the MSIX publisher change makes a different package identity, so installs from 0.28.1 or earlier need an uninstall rather than an upgrade (and a packaged app's settings go with it, so the client pairs again); a silent UPGRADE reuses the task selection the previous install recorded instead of the wizard defaults, so a once-declined installgamepad silently keeps stale gamepad drivers; installaudiocable stopped being a task name in 4a621de6; and Add-AppxPackage from a non-interactive session can fail 0x80070005 when the Windows App Runtime it depends on is in use.

enricobuehler merged commit d886cd0124 into main 2026-08-14 22:05:55 +00:00

enricobuehler deleted branch worktree-docs-azure-signing-cert-import 2026-08-14 22:05:56 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#238