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 the publisher change in omarchy-mac/omarchy-pkgs-aarch64#28.

Update the fresh installer and private channel trust to establish the new key, require keyring revision -2 or newer, and add a successor migration for clients that completed earlier trust migrations. Existing installed keys are not deleted or revoked.

This stays on the RC4 bootstrap policy: all four repository templates and the channel policy renderer retain the reviewed RC4 behavior. Existing stricter client policies are preserved. The strict RC5 migration is absent, and the version remains 4.0.3rc4.

Validation:

• Eleven focused shell suites pass, including bootstrap policy preservation, pending/completed migration behavior, installer trust and package dependency contracts.
• Actual keyring package tests pass for uninitialized trust, fresh installation and prior-version upgrade preserving unrelated trust.
• Nine native ARM transaction cases pass inside isolated synthetic roots.
• Five unsigned qualification packages built offline using pinned recipes and cached sources; payloads, root ownership, new keyring bytes, migration delivery and fresh-user markers verified.
• All five qualification archives passed the corrected publisher's local verification and staging.

Qualification used an isolated filesystem and no production signing secrets or host package installation. The opt-in native package regression test requires the saved prior public-package commit 61e7f31a3b47608325998cad5a1e8912f559e7cb locally; default fixture tests do not require it. These results do not establish physical Mac delivery. Publication requires a reviewed current repository inventory and unchanged archive reuse before RC4, followed by actual client trust validation before signed RC5 or edge conversion.

CI follow-up: simplify the single-key channel checks to satisfy ShellCheck SC2066. The exact ShellCheck 0.9.0 CI command, four affected fixture suites, and all nine native transaction cases pass at 55542531. The affected omarchy qualification archive was rebuilt from that clean commit, with the other four archives reused by verified hash; all five passed publisher verification again. Hosted checks are tracked on the PR.

[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.

[wesleygrimes]

Is this migration still needed alongside 1789407944.sh? Both populate omarchy-mac and verify the same primary, but their gates disagree: this one accepts any installed omarchy-mac-keyring (so a 20260913-1 install with only the old key passes the gate, populates, and then fails the fingerprint grep with no explanatory message), while 944 requires >=20260914-2 and gives a clear error. 468 was never on quattro, so no client has completed it. Fresh clients currently run three populates (115, 468, 944). Suggest dropping this file, or documenting why both successors must coexist.

[scottjones]

Agreed, and dropping it also removes a live bug rather than just redundancy.

468 uses return 1 at script top level, but bin/omarchy-migrate executes migrations rather than sourcing them (bash -euo pipefail "$file", line 94). So the failure path you describe actually looks like this:

$ omarchy-pkg-missing() { return 0; }; export -f omarchy-pkg-missing
$ bash -euo pipefail migrations/1789390468.sh
Populate Omarchy Mac signing trust with the new key
Install the reviewed Omarchy Mac keyring transition before activating the replacement signer.
migrations/1789390468.sh: line 7: return: can only `return' from a function or sourced script
exit=2

944 correctly uses exit 1, so this is 468-only.

Worth noting the suites do reach this path and pass over it: the package case in omarchy-mac-keyring-transition-test.sh sets TEST_PACKAGE_PRESENT=0 and hits exactly this branch, but only asserts a non-zero exit and an unset marker, so the bash error on stderr goes unobserved. If 468 stays for some reason, that assertion should also pin the stderr text.

[wesleygrimes]

This fallback is a developer-specific home path. Use a neutral default (e.g. ${XDG_CACHE_HOME:-$HOME/.cache}/omarchy-test or just require TMPDIR to be set and fail otherwise).

[wesleygrimes]

This is the only test that exercises the real 20260914-1 → 20260914-2 upgrade path (post_upgrade restoring the new key, old and unrelated trust preserved), and it is skipped by default and depends on a commit that only exists locally. Since this PR is the trust transition, either wire it into the hosted ARM job or add the upgrade scenario explicitly to the canary checklist before RC4 publication so it is not silently untested.

[scottjones]

Seconding this, and it is a harder blocker than "exists only locally" — the pinned baseline is not in this repository at all:

$ git cat-file -t 61e7f31a3b47608325998cad5a1e8912f559e7cb
fatal: git cat-file: could not get object info
$ gh api repos/omacom/omarchy-mac/commits/61e7f31a3b47608325998cad5a1e8912f559e7cb
gh: No commit found for SHA: 61e7f31a3b47608325998cad5a1e8912f559e7cb (HTTP 422)

git ls-remote finds it on no ref either. So setting OMARCHY_RUN_NATIVE_KEYRING_TEST=1 cannot work for any reviewer or CI runner — the git show "$baseline:..." calls fail before makepkg is ever reached. The only coverage of the actual 20260914-1 → -2 transition, which is the substance of this PR, is unrunnable by anyone but the author's machine, and will stay that way even if the job is wired up.

Wiring it into the hosted ARM job therefore is not sufficient on its own. The prior PKGBUILD, .install and the three keyring files need to be committed as a fixture under test/ (or the baseline re-pointed at a commit that is actually pushed) before the opt-in path means anything. The canary-checklist route you suggest would work as an interim, but I would not want it to be the permanent answer for the one transition this release is about.

[wesleygrimes]

Two things worth one sentence each here:

1. Why the primary changed from F3C5AE3F… to FBD6874D… (housekeeping before first publication, not a compromise).
2. That omarchy-mac-revoked is empty and pacman-key --populate does not remove keys, so machines that already installed the earlier keyring keep both primaries trusted, while fresh installs trust only the new one. The native test asserts exactly this, but the doc currently reads as if only the new key exists anywhere.

[wesleygrimes]

The 1789317000.sh marker here models machines that already ran #436's strict-signing migration. Those machines now have PackageRequired DatabaseRequired TrustedOnly on omarchy-aarch64, and this PR deliberately preserves stricter policies, so they cannot install the unsigned RC4 packages at all. Worth calling out in the rollout notes: any dev/canary host that ran the stacked rc5 branch needs a policy reset (or reinstall) before it can act as an RC4 canary.

[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.

[scottjones]

This is an already-shipped migration edited in place, and its failure mode is silent — which combines badly with the publication ordering described in the PR body.

Clients that already ran 115 have a marker and are unaffected; they pick up the new key through 944. But a client that has not yet run it now executes the new version: omarchy-pkg-add omarchy-mac-keyring with no version constraint, then a bare grep -qF for the new fingerprint. If the repo is still serving 20260913-1 / 20260914-1 at that moment — and the PR body says publication follows this merge — the populate succeeds with the old key, the grep fails with no message, set -e aborts omarchy-migrate, and every later migration never runs. That includes 944, the one migration with a clear explanatory error.

So the failure surfaces as omarchy update dying with no output, and the migration that would have explained it is the one that got skipped.

Wesley flagged this silent-grep shape on 468. It matters more here because 115 runs first and gates the rest of the queue. Suggest either giving 115 the same version gate and message as 944, or pinning the install: omarchy-pkg-add 'omarchy-mac-keyring>=20260914-2'.

[scottjones]

The new function landed between the existing comment and the function that comment describes, so

# Preflight has no installed-package/config/keyring side effects. The caller
# retains this directory until applying or abandoning the captured transaction.

now reads as documentation for omarchy_arm_channel_trust_fork rather than for omarchy_arm_channel_prepare. Moving trust_fork above that comment block restores it.

[scottjones]

After this PR the primary fingerprint is hardcoded in six places: here, active_key in arm-channel.sh, all three migrations, and default/pacman/keyrings/omarchy-mac-trusted — plus a literal in each of the new test files.

install.sh already sources arm-channel.sh, so at minimum those two could share one constant rather than declaring the same 40 hex characters twice. This PR is itself the evidence that rotations happen; right now performing one means a six-file grep with no single source of truth to check against.

[scottjones]

This went from four lines of sed to ~45 lines of array and regex machinery. It is correct as far as I can tell — I confirmed the pattern does not false-positive on a neighbouring name like 'omarchy-mac-keyring-extra' (the optional group requires an operator, so the closing quote never matches), and the new contract tests genuinely cover shared lines, trailing comments and stronger existing bounds.

Two things anyway:

1. The generality is speculative. Multiple dependencies on one line with a trailing comment is a shape the actual omarchy PKGBUILD does not have, and the tests construct it themselves to exercise the new code. A narrower change that just bumps the pin would be a lot less surface to reason about later.
2. scan, token, suffix are thin against the repo's full-English-name guidance — remaining_line, dependency_token, version_constraint would read the way the rest of this file does.