Skip to content

Require signatures in 4.0.3rc5 - #436

Open
malik-na wants to merge 1 commit into
quattrofrom
codex/release-4.0.3-signed-rc
Open

malik-na wants to merge 1 commit into
quattrofrom
codex/release-4.0.3-signed-rc

Conversation

@malik-na

Copy link
Copy Markdown
Member

Problem

This is the second half of the fork signing transition. The rc4 parent branch delivers and populates omarchy-mac-keyring under the final disclosed unsigned transaction. This stacked change makes 4.0.3rc5 the signed candidate and refuses unsigned or untrusted fork packages and databases.

Changes

  • Bumps 4.0.3rc4 to 4.0.3rc5; the signed candidate must be rebuilt and cannot reuse rc4 archives.
  • Changes all four shipped ARM pacman templates to PackageRequired DatabaseRequired TrustedOnly for omarchy-aarch64 only.
  • Makes fresh channel rendering strict whether the base has no fork stanza or an existing managed Optional TrustAll stanza. Other repositories and the active configuration remain unchanged during preflight.
  • Uses the rc4-pinned public key in the isolated preflight keyring, verifies the full primary fingerprint, and locally trusts it with a disposable preflight-only key.
  • Adds a successor migration that requires the bootstrap keyring to exist, repopulates it, verifies the exact primary fingerprint, atomically applies strict policy, and verifies the effective result with pacman-conf.
  • A skipped bootstrap fails the migration and remains pending; the code never fetches an unspecified key or relaxes policy to recover.

Validation

  • Nine focused signing/bootstrap/channel/build suites pass locally.
  • Effective policy readback passes for all four templates: package required/trusted and database required/trusted.
  • The strict migration fixture proves fork-only modification, other-repository preservation, exact keyring population, and fail-closed behavior when rc4 trust is absent.
  • Independent review found the initial existing-stanza fresh-install gap; the correction now applies strict policy before preflight for both existing and missing managed stanzas. Corrected arm-channel, install-channel, and migration suites pass, and the reviewer reports no remaining source blocker in this bounded diff.

Stack and release order

Base: codex/release-4.0.3-rc-20260913 / PR #435.

Do not merge or publish this ahead of the rc4 trust bootstrap. After rc4 is installed on the canary, seal and publish the complete signed 52-package repository/database, then build rc5 from this exact source and run fresh, rc4-to-rc5, skipped-bootstrap, reboot, desktop and rollback checks. Publish only to rc; stable promotion requires the canary result and separately rebuilt final bytes.

No package, lane or stable release is published by this PR.

@malik-na
malik-na force-pushed the codex/release-4.0.3-signed-rc branch 2 times, most recently from 871c6d9 to 8b28842 Compare September 13, 2026 16:55
@malik-na
malik-na added this pull request to stack #437 September 13, 2026 17:02
@malik-na

Copy link
Copy Markdown
Member Author

Current hosted ARM gate

The stacked source and shell matrices pass at 8b288420, but the live ARM install job is expected to remain red until the release sequence reaches the signed-repository step. It currently fails closed while fetching omarchy-aarch64.db.sig: the existing rc lane returns HTTP 404, followed by pacman's missing required signature / invalid database error.

This is the strict policy working as designed. Do not relax it or merge this PR ahead of #435. Merge and publish the rc4 trust bootstrap first, verify the key on the canary, merge omarchy-mac/omarchy-pkgs-aarch64#26 and publish the complete signed 52-package/database baseline, then rerun this ARM job. A green rerun will be evidence that the same stacked rc5 source can perform a fresh strict install from the signed lane.

Base automatically changed from codex/release-4.0.3-rc-20260913 to quattro September 13, 2026 17:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant