Finalize RC4 bootstrap keyring without activating strict signing

[malik-na]

Finalize the RC4 bootstrap keyring before enabling signed RC5. Ship only primary FBD6874D423C418DDB6D143EECE19CDDE306DBD2 in omarchy-mac-keyring version 20260914-2, matching omarchy-mac/omarchy-pkgs-aarch64#28. Fresh installation and private channel trust use the new primary; previously installed old and unrelated trust is preserved.

The version stays 4.0.3rc4. The four repository templates and channel policy renderer retain the reviewed RC4 behavior, including preservation of stricter existing policies. The strict RC5 migration is absent.

Review cleanup at 07753c84583aee5f112adc3d74bacdb300a7be0d:

• The pending bootstrap migration checks the installed keyring is at least 20260914-2 before its explicit trust population and reports package/version, population and fingerprint failures. The existing package helper still receives a plain package name; its skip-success case is checked explicitly.
• Remove redundant 1789390468.sh and its invalid top-level return. Retain 1789407944.sh for clients with completed earlier markers. Failed migrations remain pending and stop the queue.
• Replace the native test's unpublished Git-commit dependency with checked-in public package fixtures, checksums and provenance. Use a neutral, filesystem-checked scratch directory and explicitly enable the test in the existing disposable ARM guest.
• Document key replacement, retained old trust, package-before-migration ordering and the strict-policy canary limitation. Correct the misplaced preflight comment.

The fingerprint-constant refactor and dependency-parser simplification/naming suggestions remain deferred. All nine review conversations have responses describing what was changed, what remains unverified, or why an item was deferred; replies do not imply reviewer approval or conversation resolution.

Validation at the cleanup:

• Six focused migration/trust and CI contract/source-isolation suites pass. Tests use the real migration runner and package helpers with mocked package/privilege boundaries, including unavailable and outdated packages, successful repair, failure diagnostics and marker behavior.
• Three actual native package scenarios pass locally from a source-only directory without .git: uninitialized trust, fresh installation, and prior-version upgrade preserving old/unrelated trust.
• ShellCheck and syntax checks pass. Independent safety review found no blocking issue in the migration or native-test/CI diff.
• Full local QA passed 119 CLI assertions and 293/294 shell files with 3,420 passing shell assertions. The sole update-lock failure was previously reproduced on the unchanged baseline; this is not reported as a complete local-suite pass.
• Both hosted standard CI runs passed: https://github.com/omacom/omarchy-mac/actions/runs/34933608147 and https://github.com/omacom/omarchy-mac/actions/runs/34933604428 .
• ARM Install VM is currently failing: https://github.com/omacom/omarchy-mac/actions/runs/34933608090 . The fixture checksums and both package builds passed, then nested bubblewrap stopped with bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted before any native scenario executed. Hosted native install/upgrade coverage is still unresolved. No host protection was relaxed and no test was silently skipped.

Earlier qualification archives built from 55542531 predate the review cleanup and are historical evidence, not publishable artifacts of the current head. No production signing secrets, host trust stores, tags or releases were changed. Publication still requires a reviewed current inventory, correct archive reuse and actual fresh/existing Mac qualification. Clients must receive the RC4 trust bootstrap before signed RC5 or edge conversion.

[wesleygrimes]

Direction and sequencing look right: no template policy change, no strict migration, version stays rc4, and the build contract now enforces the versioned keyring dependency to match omarchy-mac/omarchy-pkgs-aarch64#28. Verified the committed keyring binaries: base quattro holds only F3C5AE3F…/6C2597C6…, this branch holds only FBD6874D…/D791ED0C….

One cross-PR note: #436 still pins the old primary and subkey in 1789317000.sh, the docs, and its test fixture, so it needs a rebase onto this before it can merge.

Inline comments cover the remaining items: the apparently redundant 1789390468.sh, a hardcoded developer path in the native test, the upgrade test being skipped in hosted CI, a doc note on why the key changed and that upgraded hosts keep both keys, and the strict-policy canary edge case.

[scottjones]

Reviewed against quattro, ran the touched suites locally, and read Wesley's review.

CI is green (7/7). All six touched/added shell suites pass here — the one package-build-contract-test.sh failure I hit was a missing sibling omarchy-pkgs checkout, environmental, and it passes once linked.

Direction and sequencing look right to me too. One improvement worth naming explicitly: in omarchy_arm_channel_trust_fork the fingerprint verification now runs unconditionally, where the old code only verified when the key had just been added. A keyring that already held a wrong key under that name would previously have been lsigned without a check. Good change.

I agree with all five of Wesley's items. Two I've sharpened in-thread:

• The skipped native upgrade test is worse than "only exists locally" — the pinned baseline commit is not in the repo at all (GitHub returns 422 for it), so the opt-in flag cannot work for anyone but the author.
• Dropping 1789390468.sh also removes a live bug: it uses return at script top level, but migrations are executed rather than sourced.

Four further items inline. None of them block on their own, but the first is a rollout-ordering hazard I'd want settled before publication.

Cross-PR: confirmed #436 still pins F3C5AE3F… in 1789317000.sh, so Wesley's rebase note holds.

[malik-na]

Review follow-up at 1b117466:

Resolved as implemented and verified: redundant/broken 1789390468 removal; neutral disk-backed scratch selection; committed reproducible 20260914-1 fixture; key-rotation/trust-preservation documentation; strict-policy canary exclusion; the 1789316115 version/error gate; and the misplaced helper comment.

The native keyring test passed directly in the Arch ARM UTM VM for uninitialized, fresh-install, and real 20260914-1 → 20260914-2 upgrade scenarios. The Ubuntu/nspawn workflow no longer claims nested native-keyring coverage; the RC4 qualification checklist remains explicit. All exact-head CI checks are green.

Left open intentionally as non-blocking follow-ups: consolidating the active fingerprint constant and simplifying/renaming the dependency parser.

[malik-na]

Required merge and rollout order

The PR dependency order is:

1. omarchy-pkgs-aarch64#28 — merged.
2. This RC4 bootstrap PR (omacom/omarchy-mac#444).
3. The strict-signing RC5 PR (omacom/omarchy-mac#436).

Publication gates are part of that order; merging the source PRs alone is not sufficient:

1. Publish omarchy-mac-keyring 20260914-2 and the RC4 packages built from the reviewed #444 head.
2. Confirm the repository exposes the expected versions and that omarchy requires omarchy-mac-keyring>=20260914-2.
3. Complete the clean-install and upgrade checks in the Arch ARM UTM VM.
4. Merge #444, then verify a real client update completes the bootstrap migrations. Keep issue #446 open until this deployed-path check succeeds.
5. Rebase/update #436 on the merged #444, including replacing any stale fingerprint assumptions.
6. Build, sign, publish, and canary-test the RC5 package set and repository database.
7. Merge #436 only after a bootstrapped client successfully consumes those signed artifacts under the intended strict policy.

In short: #28 → publish and verify RC4 bootstrap artifacts → #444 → verify deployed bootstrap → prepare and canary signed RC5 → #436.

Do not merge #444 while its required keyring package is unavailable, and do not merge #436 before the #444 bootstrap has been deployed and verified.

[scottjones]

Re-reviewed at 1b117466. Verified the fixes rather than taking them on trust:

• 115's new gate behaves as described — against an installed 20260913-1 it now exits 1 with Omarchy Mac keyring 20260914-2 or newer is required (installed: 20260913-1); … and makes no pacman-key call, where the previous version aborted the whole queue silently. The nine-scenario queue test covers old-only and install-old, which is exactly the publication-ordering hazard.
• 1789390468.sh is gone, and both suites now assert against its top-level return error rather than just a non-zero exit.
• Fixture checksums verify clean; the test runs with no .git present.
• The preflight comment is back above omarchy_arm_channel_prepare.

All eight suites this PR touches pass here, and CI is green on the exact head. For the two failures in my full-suite run (install-vm-source-isolation, plymouth-set): they reproduce identically on unmodified quattro under the same environment, so they are my local setup, not this branch. The five test files this PR adds all pass.

I also want to note the handling of the hosted-CI item: removing the nspawn wiring and adding assertions that stop that job from re-claiming the coverage is a better outcome than leaving it in place and calling it covered. Same for marking the install.sh constant and the build-packages.sh parser as deferred rather than folding them in silently — no objection to either deferral, neither was a correctness issue.

One small follow-up inline, not a blocker.