Revert USB and Thunderbolt authorization and undo installed protection

[omarchybot]

Reverts #11874 (5cb31317b488dce2734c867fd9dc21f9fb7a7e9a) and removes its installed protection, restoring the previous behavior for USB and Thunderbolt accessories at the maintainer’s request. This intentionally removes the mandatory approval barrier that #11874 added.

A source revert alone would leave USBGuard blocking devices without approval commands and Bolt’s saved authorization settings and boot restrictions in place. The upgrade migration restores permissive USB boot images and snapshot metadata before stopping USBGuard, restores live USB authorization for existing and newly registered host controllers, hands Omarchy-enrolled Bolt records back to automatic policy while preserving independent manual policies and saved secure keys, restores the saved firmware allowlists and original Bolt authorization mode, and retires watcher enable links and copied Polkit definitions. Signed USB image conversion and transactional Bolt recovery remain under the migration directory solely to undo the state already deployed. Independent Thunderbolt, USB and factory repairs all run even if another fails. Failures leave the migration pending and retain recovery data; Thunderbolt handoff requires the original controllers to be online. A verified USB boot-removal receipt preserves ownership across failed enforcement removal and is tied to the running boot when bypassing the boot-deny interlock, allowing retries before reboot. A manual default-deny kernel parameter in the running boot keeps USBGuard in place until the administrator removes the parameter, rebuilds, reboots and retries. USB boot changes take effect after reboot. Signed USB image conversion requires the existing signing keys and temporary disk space; custom measured-boot or multi-profile images require their original builder.

An existing factory snapshot is repaired without reenrolling accessories on the next reset, while preserving its original Bolt mode and read-only status across retries. Factory script repairs publish complete files atomically. Factory reset also repairs the staged clone and retained baseline before activation, so it remains safe before the login migration runs. Root rollback is serialized across users and records machine-wide completion; later users need no sudo for their own watcher cleanup. Fresh machines without feature residue skip root work. Running watchers are stopped even when package removal has erased their unit files or privileged rollback fails, and dangling enable links are removed. A user checkpoint keeps unfinished root work pending after watcher cleanup.

Removes the feature’s user-facing commands, install and provisioning enrollment, menu entries, policy definitions, enrollment migrations, documentation, and approval tests. Preserves later unrelated fixes, including per-unit first-run startup and the LUKS provisioning completion guard. USB removal requires Omarchy-generated policy or marked boot settings; an unrelated kernel parameter or watcher alone does not disable manual USBGuard policy. Known Omarchy IPC grants are archived outside USBGuard; custom grants are preserved, and the installed USBGuard package is left in place. Recovery root units execute only the packaged helper, with compatibility units retained unchanged while removal is incomplete. Package updates can restore these units without breaking a retry; after removal, their marker condition fails and the Bolt guard does nothing. Saved USB rules, disabled Omarchy trust records, and live Bolt keys are retained. Hidden daemon and guard-only compatibility entrypoints retain the original boot unit and Bolt guard while installed protection awaits removal, including a reboot before the user migration runs. Historical system snapshots still contain their original software; after restoring one, update and rerun the rollback with rm -f ~/.local/state/omarchy/migrations/1791673477.sh && omarchy-migrate, because per-user migration markers in /home survive a root snapshot restore.

No separate issue is closed.

[omarchybot]

GPT-6 in Codex reviewed this revert and its installed-state migration. Codex Medium supplied the required second opinion, contributed checks for cold Bolt startup, factory mode and read-only recovery, and interrupted file publication, and found no remaining actionable defects at 517dddc88530d98f80e2f9ef57a18286731ec94c. The second opinion inspected source read-only; its final agreement does not guarantee independence.

Verification ran on disposable ISO workers without credentials. The CLI suite, affected provisioning and menu tests, signed USB archive and enrollment tests, and new rollback regressions passed. Mutation checks proved that the regressions reject the reviewed failure paths. A native migration with real USBGuard, Bolt, systemd and kernel USB authorization passed, including a stopped legacy watcher unit fixture, cold Bolt startup, protected root startup and repeated execution. The Security menu was inspected on the worker desktop.

The complete candidate suite recorded 5,506 passing assertions and failures in eight files: ascii-test.sh, branding-about-animation-test.sh, default-agent-test.sh, hyprland-startup-cursor-cold-test.sh, passwordless-grant-lifecycle-test.sh, preinstalls-test.sh, runtime-smoke-test.sh, and screenshot-sanity-test.sh. Each failing file also fails on unchanged quattro at f2a39c4d; the preinstall assertion is intermittent and passed immediate reruns on both trees. Two candidate test files contained skipped checks: brightness-display-apple-cache-test.sh and kitty-config-test.sh. The final review was the sixth round within a seven-round bound and ended with no remaining finding.

Physical Thunderbolt firmware restoration was not exercised; the worker has no such controller. Signed boot conversion requires the original signing keys, temporary space and any custom image builder, and firmware restoration requires the original controllers to be online. Failed rollback keeps the migration pending and recovery data intact. USB boot changes require a reboot. This intentionally removes the approval barrier added by #11874. Waiting on the maintainer to decide whether to land it.

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The changes since the previous review appear safe to merge.

Summary

This PR removes USB and Thunderbolt approval and adds a migration to undo installed protection.

• Omarchy no longer enrolls accessories or offers its approval controls.
• The migration restores the USB and Thunderbolt settings Omarchy changed.
• Factory reset repairs staged systems and snapshots before they are used.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Start USB rollback] --> B[Read running boot identity]
  B --> C{Omarchy boot removal pending?}
  C -->|Yes| D[Rebuild and verify permissive boot images]
  D --> E[Save receipt with boot identity]
  C -->|No| F{Omarchy USB ownership or saved receipt?}
  E --> F
  F -->|No| G[Leave USBGuard unchanged]
  F -->|Yes| H{Running boot denies USB?}
  H -->|No| J[Stop USBGuard and restore live USB access]
  H -->|Yes| I{Receipt matches running boot?}
  I -->|Yes| J
  I -->|No| K[Keep USBGuard and leave migration pending]

Loading

_{Reviews (5) · Last reviewed commit: "Keep USB boot ownership across failed re..." · Reviewed by Greptile}

[acrogenesis]

Confirmed a remaining P2 at 517dddc88530d98f80e2f9ef57a18286731ec94c: the watcher cleanup in migrations/1791673477.sh:13–24 can succeed while leaving a dangling graphical-session.target.wants/<unit> link.

With the main unit symlink pointing into a missing checkout, LoadState=not-found skips disable. systemctl is-enabled also reports not-found (exit 4), even though the wants link still exists. The migration then retires the main symlink and reports completion; the next graphical session still requests the missing service.

I reproduced this using the actual migration in an isolated fixture, with real offline systemctl for enabled-state resolution. The minimal systemctl behavior is:

fixture=$(mktemp -d)
unit=omarchy-thunderbolt-authorization.service
mkdir -p "$fixture/etc/systemd/system/graphical-session.target.wants"
ln -s /missing/checkout/unit "$fixture/etc/systemd/system/$unit"
ln -s "../$unit" "$fixture/etc/systemd/system/graphical-session.target.wants/$unit"
systemctl --root="$fixture" is-enabled "$unit" # not-found, exit 4

Please explicitly remove the retired watchers' enablement symlinks even when the main unit is missing, and add the wants-link fixture to the migration regression. Keep failures stopping active services fatal. The existing dangling-unit test covers only the main link, so it currently passes without catching this.

This affects our #14936/#14937 cleanup too; I am fixing those. I separately verified that this PR handles the missing-marker Thunderbolt recovery and stopped-Bolt cases and repairs the old factory enrollment code, which our versions had missed.

[omarchybot]

Reviewed a058787cedb0056f7e35657b9fbc8dac3b8fd57a with GPT-6 in Codex and Opus 5.5 XHigh in Claude Code. The rollback protects both staged and retained factory roots before reset activation, stops running watchers after their unit files disappear, and attempts independent repairs even if another fails. Machine-wide completion avoids repeated sudo for later users; a user checkpoint preserves retries after failed root work. USB ownership requires Omarchy-generated policy or marked boot settings, obsolete IPC grants are archived outside USBGuard, and persistent root recovery units use the packaged helper. Hidden daemon and guard-only boot bridges remain usable if the machine reboots before the user migration, and the live USB module default permits newly registered controllers after USBGuard stops. Reset repair errors reach the advertised log. Package-owned root units stay unchanged and become inert after marker removal, allowing retry after package reinstatement. A manually added default-deny boot parameter keeps USBGuard enabled; a verified boot-removal receipt preserves ownership for later users after failed enforcement removal and bypasses that interlock only during the same running boot. The running boot identity is checked once before conversion; regressions assert that the generated receipt leads to disabled enforcement and restored live input.

On a disposable worker, the exact-head full suite recorded 5,533 passing assertions. Seven failing files also fail on the unchanged base: ASCII width, branding animation, agent migration, cold compositor startup, passwordless grant lifecycle, bar ordering, and screenshot sanity. Apple brightness-cache and Kitty configuration checks were skipped. Focused rollback regressions pass as both user and root; twenty-one deliberate removals of fixes make their regressions fail, and the restored tree passes. Native systemd, USBGuard and Bolt checks pass, including a running not-found watcher, a package-owned recovery daemon publishing snapshots, IPC retirement and a non-wheel second user requiring no sudo. A real pre-migration reboot retained Bolt and the recovery daemon, and the real packaged reset-root action repaired a fixture and logged rejected custom enrollment. Using real dummy_hcd controllers, the previous published helper (e1fbcef4) reproduces a newly registered controller defaulting to deny, while the final helper defaults it to allow. Physical Thunderbolt controller and firmware behavior was not exercised.

Historical compatibility concerns were checked against the merge history: the original batch and later per-unit first-run forms are both covered, and original_authmode was present in the first Thunderbolt implementation. USB-only development commits were merged together with Thunderbolt in #11874. Generated USB policies contain a root-visible portable label or empty-enrollment comment, so their detection works regardless of which user upgrades first; stripping those labels is a manual policy edit. Scanning every user’s writable marker would risk false ownership of manual policies. Snapshot recovery instructions now clear the per-user migration marker before rerunning the rollback. The package-reinstatement failure was reproduced natively on the previous head; the updated helper succeeds and preserves both files byte-for-byte. The shared signed-image and Bolt transaction engine is retained to undo deployed state; its public enable entrypoint is removed.

Opus 5.5 XHigh in Claude Code’s final static pass found no blocking defects and confirmed the receipt, ownership and retry changes. Its optional test-ordering assertion would strengthen coverage; the source already reads the boot identity before conversion. Optional receipt symlink hardening requires an unprivileged writer under the state path, which is root-owned and mode 0755 in the native install; no such writer was found. Five Claude passes were completed, including two focused confirmations beyond the initial three-pass plan. Claude contributed verified failure mechanisms; independence of the final agreement is not guaranteed because the confirmation prompts include the checked findings and repairs. The branch awaits the maintainer’s decision. Greptile’s separate automated review was still running when this report was posted.