Let the Mac's platform package name the keyrings omarchy update refreshes - #667
Merged
Merged
Conversation
…shes omarchy-mac now ships /usr/share/omarchy-platform/keyrings naming asahi-alarm-keyring, and omarchy-update-keyring reinstalls and populates each installed keyring that file names, deriving the pacman-key rings from the files each package owns. Upstream's update has no Apple branch for [asahi-alarm], so the Mac's own package has to say which keyring to keep current; the same few lines read the file there. A Mac whose omarchy-mac predates the file keeps the Apple fallback.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#652 kept asahi-alarm-keyring current through an Apple branch in quattro-upstream's
omarchy-update-keyring. Upstream's version (omacom#13362) refreshes only Arch's and Arch Linux ARM's keyrings, so once Macs run it an Asahi key rotation would fail the upgrade's signature checks./usr/share/omarchy-platform/keyringsnamingasahi-alarm-keyring.omarchy-update-keyringreinstalls each installed keyring that file names with the others, before the system upgrade. Names are validated (anything but a*-keyringpackage stops the update), uninstalled ones are skipped, and the rings to populate come from the/usr/share/pacman/keyrings/*.gpgfiles each package owns, read again after the reinstall.Nothing in omarchy-mac alone can do this on omacom#13362's runtime: its update runs no platform step before the upgrade, and a pacman hook runs after signature checks and under the database lock. omacom#13362 needs the same few lines; the patch is in ticket 103's operations folder (
13362-platform-keyrings.patch, tested against df41281), for the owner to apply there.Testing (Arch container, non-root):
update-keyring-test.sh(rewritten: platform list cases, invalid names, a package without a keyring, ring rename after reinstall, failure propagation),update-sequence-test.sh,apple-platform-hooks-test.sh, omarchy-mac'stest/all. Second review: no blocking findings; its one hardening note (read the file list line by line) is applied. The design was debated once more beforehand; the platform-root file won over refreshing every installed keyring or a new dispatch operation.