ZacharyZhang-NY/omarchycn
4
5
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases 5 Wiki Activity

Repair legacy XCompose and vulnerable power paths

Browse Source
This commit is contained in:
Ryan Hughes
2026-08-30 11:36:22 -04:00
parent e3b566bae8
commit 8add7b49de
4 changed files with 613 additions and 179 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agents/skills/migrations.md
+1 -11
View File
@@ -167,14 +167,4 @@ Omarchy 4.0 is upgraded through `bin/omarchy-upgrade-to-quattro`, not through th
normal migration runner. Do not add compatibility migrations for old installer
layouts; put pre-4 package-layout transition work in the upgrade command instead.
Clearing a privileged file that a retired installer left on disk is the exception,
and belongs in a migration whether or not that installer was part of a package
layout transition. The upgrade command only runs on a machine still making the 3
to 4 crossing, so anything put there never reaches an install that crossed
already, and it never runs at all for an installer that was retired on its own —
while the file the installer wrote is still sitting on those machines. The upgrade
command finishes by running `omarchy-migrate` (`run_post_upgrade_migrations`), so
one migration reaches every population; a copy in the upgrade command would only
be a second copy of the same predicate to keep correct. Such a migration must name
the defect it clears and match what the old installer actually produced, so a file
an administrator wrote themselves is left alone.
Clearing a privileged file that a retired installer left on disk is the exception, and belongs in a migration whether or not that installer was part of a package layout transition. The upgrade command only runs on a machine still making the 3 to 4 crossing, so anything put there never reaches an install that crossed already, and it never runs at all for an installer that was retired on its own — while the file the installer wrote is still sitting on those machines. The upgrade command finishes by running `omarchy-migrate` (`run_post_upgrade_migrations`), so one migration reaches every population; a copy in the upgrade command would only be a second copy of the same predicate to keep correct. Such a migration must name the defect it clears and match what the old installer actually produced before deleting it. Leave safe administrator-authored files alone; if one still contains the vulnerable privileged action, preserve it under an inactive name rather than discarding custom content or leaving the action executable. A user config that depends on the same retired compatibility path may be repaired in that migration when doing so eliminates an overlapping migration, but only by matching and replacing the exact legacy path while preserving the rest of the file.