Matching a legacy grant by its filename and rule relationship is not a
complete fingerprint: the legacy writer took the filename from $USER but
produced the rule with echo, and under BASH_ENV with xpg_echo a name such
as ali\0143e yields an alice rule in a mismatched file. Preserving that
as administrator policy let the migration certify success with an
unrestricted grant still live until the next boot.
The prefix is reserved anyway: boot cleanup and the package hook remove
everything under it. Move any file the classifier does not recognize
into a fresh root-only directory under /var/lib/omarchy/sudoers-quarantine/
as `policy`, with the original name stored beside it, so nothing there
stays live, the administrator keeps the content, and a legacy filename
already close to NAME_MAX still fits. An untrusted quarantine directory
keeps the migration pending. Cover the mismatched and maximum-length
legacy files in the unit cleanup and through the real migration runner.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The legacy command wrote the caller's unvalidated name into both the
sudoers filename and the rule. Cleanup applied the current lower-case
account pattern to that suffix, so an exact legacy grant for an account
such as Alice was classified as administrator policy, left active, and
the machine-wide migration marker was written anyway.
Match a legacy grant by its exact filename and rule relationship instead
of the account policy, and cover it in the lifecycle suite through both
the unit cleanup and the real migration runner.
The account pattern itself stays lower-case: sudoers reads an upper-case
word such as ALICE as a User_Alias reference, and ALL as every user, so
such names must never reach the generated rule. Pin that with a test.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Upstream now runs every Omarchy-owned pacman transaction through the
hidden omarchy-update-pacman helper so a mid-transaction systemd reexec
cannot kill it. Keep the deferred pre-refresh-pacman hook and the
command-scoped sudo wrapper, and call the helper from the refresh and
channel commands; the wrapper still applies to the helper's own sudo.
The sudo boundary fixture copies the helper into its root and runs a
systemd-run stand-in that execs the wrapped pacman step in place.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
* Remove unsafe project bin PATH injection
* Cover customized unsafe Mise paths
* Revoke legacy Mise Work trust
* Harden legacy Mise trust cleanup
* Preserve ignored Mise Work configs
* Scope Mise path cleanup to env
* Accept paranoid Mise ignore marker
Reported-by: infosec-us-team
* Keep screen-recording state out of world-writable /tmp
* Compare the /tmp name across the run instead of requiring it absent
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Fall back to the state directory when there is no runtime dir
* Let the /tmp snapshot come back empty
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Resolve the region file the same way in the resizer
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Protect recording fallback state and document its path
---------
Co-authored-by: Omabot <omabot@omarchy.org>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
publicPluginManifest() stripped __sourceDir from every non-first-party
manifest, but service and panel plugin instances receive only that
stripped manifest and no separate sourceDir (unlike barWidgets, which
get meta.sourceDir). That left third-party service/panel plugins with
no way to locate their own bundled scripts and assets: any plugin that
launches a bundled script resolves it against an empty base path and
fails silently (e.g. Omarchy-Spotify hangs on "Checking playback
support…", its keyring/credential scripts never run).
__sourceDir is the plugin's own install directory, not a privilege
signal — the plugin's code already runs from there. Keep withholding
the real privilege markers (__isFirstParty, __hostCapabilities) but
stop stripping __sourceDir. The plugin auth-boundary test suite still
passes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
No branch on the repo is protected and there are no rulesets, so the
file never enforced owner review. Its only effect was auto-requesting a
review from the other owner on every PR, which nobody acted on.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
