Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy repo signing key exists in keyring but SigLevel still Optional TrustAll (follow-up to #2712)
Reported by drneb99 · filed Aug 30, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
Title: omarchy repo signing key exists in keyring but SigLevel still Optional TrustAll (follow-up to #2712)
Body:
Follow-up to #2712, which is locked so I can't comment there directly.
That issue (closed as Completed on 2026-07-18) discussed switching the [omarchy] repo to require signed packages. On a current Omarchy 4.0.1 install, the signing key infrastructure discussed there does appear to be in place — the Omarchy <[email protected]> key, fingerprint ending F0134EE680CAC571, is present in /etc/pacman.d/gnupg — but enforcement doesn't seem to have actually shipped:
$ grep -A2 '^\[omarchy\]' /etc/pacman.conf
[omarchy]
SigLevel = Optional TrustAll
Server = https://pkgs.omarchy.org/stable/$archWith SigLevel = Optional TrustAll, pacman still won't require or meaningfully verify signatures from this repo, even though a trusted key now exists in the keyring — so packages are apparently being signed on the build side, but clients aren't configured to actually check that. Compare to the official Arch repos in the same file, which use SigLevel = Required DatabaseOptional.
Questions:
- Was the SigLevel change intentionally held back (e.g. still rolling out signing to all packages before enforcing)?
- Or is this a case where existing installs' pacman.conf didn't pick up a config change that new installs get?
Happy to provide more detail on my setup if useful.
System info: Omarchy 4.0.1 (BUILD_ID 4.0.1)
View raw text
Title: omarchy repo signing key exists in keyring but SigLevel still Optional TrustAll (follow-up to #2712) Body: Follow-up to #2712, which is locked so I can't comment there directly. That issue (closed as Completed on 2026-07-18) discussed switching the `[omarchy]` repo to require signed packages. On a current Omarchy 4.0.1 install, the signing key infrastructure discussed there does appear to be in place — the `Omarchy <[email protected]>` key, fingerprint ending `F0134EE680CAC571`, is present in `/etc/pacman.d/gnupg` — but enforcement doesn't seem to have actually shipped: ``` $ grep -A2 '^\[omarchy\]' /etc/pacman.conf [omarchy] SigLevel = Optional TrustAll Server = https://pkgs.omarchy.org/stable/$arch ``` With `SigLevel = Optional TrustAll`, pacman still won't require or meaningfully verify signatures from this repo, even though a trusted key now exists in the keyring — so packages are apparently being signed on the build side, but clients aren't configured to actually check that. Compare to the official Arch repos in the same file, which use `SigLevel = Required DatabaseOptional`. Questions: - Was the `SigLevel` change intentionally held back (e.g. still rolling out signing to all packages before enforcing)? - Or is this a case where existing installs' `pacman.conf` didn't pick up a config change that new installs get? Happy to provide more detail on my setup if useful. System info: Omarchy 4.0.1 (BUILD_ID 4.0.1)
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Fixed bypr/8472· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 10:09 UTC